[Osr-101] Getting abstract (or: defining Neutron's target abstraction level)

Gregor Imboden gregor.imboden at wyona.com
Fri Sep 8 17:45:15 CEST 2006


Am Freitag, 8. September 2006 17:26 schrieb Gregor Imboden:
> Am Freitag, 8. September 2006 16:30 schrieb Andreas Wuest:
> > 1. Completely independent of the application layer protocol.
> >
> > 2. Dependent on two-way communication capable application layer
> > protocols. Independent of specific Neutron endpoints.
> >
> > 3. Dependent on two-way communication capable application layer
> > protocols. Dependent on specific Neutron endpoints.
> >
> > 4. Dependent on the HTTP application layer protocol.
> >
> > I, for one, believe that we should aim for abstraction level 2. The
> > current specification is a mixture of levels 3 and 4.
>
> But if we would go to straight to the application layer we couldn't
> implement Neutron let's say as an Apache HTTPD module (actually we could
> but whe had to mess with socket/io directly and would loose the whole HTTP
> abstraction), i think that would hinder a lot of people from implementing
> neutron.

Darn, ignore my statements about socket-io and apache, it would work perfectly 
as a cgi when we use the HTTP protocol...

>
> I would prefer level 4. without the dependency on Neutron specific
> endpoints.
>
> Gregor
>
> > In order to move towards level 2, we have to incorporate the following
> > changes:
> >   * Remove the dependency on HTTP header fields
> >   * Remove the dependency on HTTP response status codes
> >   * Remove the dependency on Neutrons specific endpoints (e.g.: if you
> > POST to this URI, you can handle Neutron exceptions in the response)
> >
> > This implies the following:
> >   * All requests have to be enveloped. The envelope has to indicate that
> > this is a Neutron request. When using the HTTP protocol, this implies
> > that GET requests are ruled out, and we have to use POST instead. This
> > enveloping ensures that the server know that it is dealing with a
> > Neutron capable client, and that it can respond with a Neutron exception
> > if need be.
> >   * IFF the server detects that the request is a Neutron request, and it
> > uses the HTTP protocol, all responses have to 200, such that the
> > response body is always routed up to the Neutron protocol handler, and
> > it can analyses its content.
> >
> > Regarding Neutron-Auth: this protocol should be downgraded to level 4.
> > Why? Because the reason for separating it from Neutron was to use it as
> > a means for authentication together with other protocols like APP or
> > Atom.
> >
> > The other possibility would be to tunnel APP or Atom requests through
> > the Neutron protocol. Then we could reintegrate Neutron-Auth into
> > Neutron.
> >
> > I am looking forward to a discussion which finally settles these issues,
> > because I am having a hard time implementing Neutron and Neutron-Auth as
> > long as it behaves as inconsistent as it currently does.
>
> _______________________________________________
> Osr-101 mailing list
> Osr-101 at wyona.org
> http://wyona.com/cgi-bin/mailman/listinfo/osr-101



More information about the Osr-101 mailing list