(^_^ I can achieve this myself using .toLowerCase().toCamelCase(); heh)
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
In the interest of Wes' Modesty Proposal and Tom's Level 0 idea, I figured I'd put together a first sketch of JSGI Level 0. If we can address the core issues and keep it simple, we can bikeshed the hell out of Level 1 without stalling development of current JSGI middleware.
Request Environment
It sounds like most people prefer hash namespacing in the env, but Tom, as an implementer, would need to be on board. However he did propose headers in their own hash -- so it may not be too presumptuous to put jsgi keys in their own hash, like so:
{
headers: {
ACCEPT: ...
...
},
jsgi: {
version: ...
input: ...
errors: ...
...
},
REQUEST_METHOD: ...
...
}
Another change to the env that was suggested: moving jsgi.url_scheme to the top level, perhaps as PROTOCOL. It certainly seems to belong there.
{requestMethodheaders"content-type": ......bodyjsgi...}
> be in the direction of a minimal /request/ object. It also provides
> symmetry with the response object (or should that otherwise be
> renamed /output environment/?).
>
> 2) Camel case
> Most people voted for camel-case properties wholesale (apart from
> headers) so REQUEST_METHOD should be requestMethod, or maybe just method.
>
> 3) Stream symmetry
> The response object names its body contents stream "body" and puts it
> in the root. Request should do the same (or response should rename
> body to output - I'm suggesting body here but both are ok I think).
> [Stream API likeness could be discussed in a different thread]
>
> 4) Putting the important stuff in first row
> The input stream "jsgi.input" shouldn't be tucked away under jsgi (as
> already suggested) as this whole structure is a JSGI request. All main
> request data properties should be put in the root, or have its own
> top-level namespace if it's a collection (like headers).
>
+1 to all this, it sounds great to me, except:
> 6) Separate place for unspecified stuff
> The root of the structure should be kept clean from user-added stuff,
> so we don't get name collisions with existing code if future revisions
> of the API adds new properties. User code-added properties should go
> into a separate collection. I'm writing "env" here, but maybe that is
> too overloaded. The Java world uses "attributes".
Why shouldn't users add stuff to the top level? Why would there be less
chances of collisions in a sub-object vs the root? If anything we should
be trying to reserve room for user information at the top level.
Kris
Dean Landolt wrote:
Request Environment
It sounds like most people prefer hash namespacing in the env, but Tom, as an implementer, would need to be on board. However he did propose headers in their own hash -- so it may not be too presumptuous to put jsgi keys in their own hash, like so:
{
headers: {
ACCEPT: ...
...
},
jsgi: {
version: ...
input: ...
errors: ...
...
},
REQUEST_METHOD: ...
...
}Comments:1) Main direction / principleA critical question on the direction of the work is if the designed data structure is supposed to mirror a CGI environment variable structure, or a request object. I prefer the latter. The former implies uppercased stuff in a flat list, and my interpretation is that most people wants to move away from that. The following comments will be in the direction of a minimal request object. It also provides symmetry with the response object (or should that otherwise be renamed output environment?).
2) Camel caseMost people voted for camel-case properties wholesale (apart from headers) so REQUEST_METHOD should be requestMethod, or maybe just method.
3) Stream symmetryThe response object names its body contents stream "body" and puts it in the root. Request should do the same (or response should rename body to output - I'm suggesting body here but both are ok I think).[Stream API likeness could be discussed in a different thread]
4) Putting the important stuff in first rowThe input stream "jsgi.input" shouldn't be tucked away under jsgi (as already suggested) as this whole structure is a JSGI request. All main request data properties should be put in the root, or have its own top-level namespace if it's a collection (like headers).5) HeadersThis seems to be mostly agreed, but if doing case shifting I would propose lowercase instead of uppercase as the latter may cause expectations that dashes should also be converted to underscores a la CGI (which they shouldn't).
6) Separate place for unspecified stuffThe root of the structure should be kept clean from user-added stuff, so we don't get name collisions with existing code if future revisions of the API adds new properties. User code-added properties should go into a separate collection. I'm writing "env" here, but maybe that is too overloaded. The Java world uses "attributes".With the comments so far we would then have:{requestMethodheaders"content-type": ......bodyjsgi...}Still there are a few things missing:7) URL propertiesThe request should probably contain data about the full URL. This can be done according to three different principles; (a) URL, (b) HTTP spec, or (c) CGI variable names:http://abc.org:80 /basepath /funcpath /extrapath ?p=1a) scheme host port path path path queryb) scheme host port requestUri requestUri requestUri queryc) https=on host port scriptName scriptName pathInfo queryStrc) requestUri requestUri requestUriTo keep things minimal, it would probably be good to choose one main principle, and then maybe fill in a few missing pieces. (If going with CGI then scriptName shouldn't be used for the server+mount path.)What's everybody's opinion here?
8) Other namespacesThere could be additional standard namespaces, f ex for physical server information. Opinions?
9) Mount pathRelated to the URL properties; should there be properties on the request that divide the path into where the application is mounted and extra pathInfo, or should there just be the total path
What do you all think?
Response
[...] The only open issue is the header hash case-sensitivity. I firmly believe we have to standardize on a Level 0 case to aid interop between Level 0 middlewares (Level 1 can fix this issue with a case-insensitive hash but if left unspecified it will cause problems at Level 0).
Thus I would suggest that JSGI Level 0 specify that response hash keys SHOULD be set as uppercase. In addition, should a non-conforming middleware set a mixed-case key and a corresponding uppercase key exists, the uppercase key SHOULD win. (it can be left up to the implementation whether to respect non-colliding mixed-case keys at all).To me, this is the worst option as it will force developers to mangle their headers to have a decent chance getting it output.My priority would be:1) Provide something like setHeader()/getHeader() methods that matches headers case-insensitively, but persists user code's first casing.2) Duck the problem and output everything that is set, duplicates and all.3) -"-4) -"-...99) Specify "SHOULD convert header casing".;-)
Dean Landolt wrote:
Request Environment
It sounds like most people prefer hash namespacing in the env, but Tom, as an implementer, would need to be on board. However he did propose headers in their own hash -- so it may not be too presumptuous to put jsgi keys in their own hash, like so:
{
headers: {
ACCEPT: ...
...
},
jsgi: {
version: ...
input: ...
errors: ...
...
},
REQUEST_METHOD: ...
...
}Comments:1) Main direction / principleA critical question on the direction of the work is if the designed data structure is supposed to mirror a CGI environment variable structure, or a request object. I prefer the latter. The former implies uppercased stuff in a flat list, and my interpretation is that most people wants to move away from that. The following comments will be in the direction of a minimal request object. It also provides symmetry with the response object (or should that otherwise be renamed output environment?).
2) Camel caseMost people voted for camel-case properties wholesale (apart from headers) so REQUEST_METHOD should be requestMethod, or maybe just method.
3) Stream symmetryThe response object names its body contents stream "body" and puts it in the root. Request should do the same (or response should rename body to output - I'm suggesting body here but both are ok I think).[Stream API likeness could be discussed in a different thread]
4) Putting the important stuff in first rowThe input stream "jsgi.input" shouldn't be tucked away under jsgi (as already suggested) as this whole structure is a JSGI request. All main request data properties should be put in the root, or have its own top-level namespace if it's a collection (like headers).
5) HeadersThis seems to be mostly agreed, but if doing case shifting I would propose lowercase instead of uppercase as the latter may cause expectations that dashes should also be converted to underscores a la CGI (which they shouldn't).
6) Separate place for unspecified stuffThe root of the structure should be kept clean from user-added stuff, so we don't get name collisions with existing code if future revisions of the API adds new properties. User code-added properties should go into a separate collection. I'm writing "env" here, but maybe that is too overloaded. The Java world uses "attributes".
With the comments so far we would then have:{requestMethodheaders"content-type": ......bodyjsgi...}Still there are a few things missing:7) URL propertiesThe request should probably contain data about the full URL. This can be done according to three different principles; (a) URL, (b) HTTP spec, or (c) CGI variable names:http://abc.org:80 /basepath /funcpath /extrapath ?p=1a) scheme host port path path path queryb) scheme host port requestUri requestUri requestUri queryc) https=on host port scriptName scriptName pathInfo queryStrc) requestUri requestUri requestUriTo keep things minimal, it would probably be good to choose one main principle, and then maybe fill in a few missing pieces. (If going with CGI then scriptName shouldn't be used for the server+mount path.)What's everybody's opinion here?
8) Other namespacesThere could be additional standard namespaces, f ex for physical server information. Opinions?
9) Mount pathRelated to the URL properties; should there be properties on the request that divide the path into where the application is mounted and extra pathInfo, or should there just be the total path?
What do you all think?
Response
[...] The only open issue is the header hash case-sensitivity. I firmly believe we have to standardize on a Level 0 case to aid interop between Level 0 middlewares (Level 1 can fix this issue with a case-insensitive hash but if left unspecified it will cause problems at Level 0).
Thus I would suggest that JSGI Level 0 specify that response hash keys SHOULD be set as uppercase. In addition, should a non-conforming middleware set a mixed-case key and a corresponding uppercase key exists, the uppercase key SHOULD win. (it can be left up to the implementation whether to respect non-colliding mixed-case keys at all).To me, this is the worst option as it will force developers to mangle their headers to have a decent chance getting it output.
My priority would be:1) Provide something like setHeader()/getHeader() methods that matches headers case-insensitively, but persists user code's first casing.2) Duck the problem and output everything that is set, duplicates and all.3) -"-4) -"-...99) Specify "SHOULD convert header casing".;-)
Great! :-)
> , except:
> > 6) Separate place for unspecified stuff
> > The root of the structure should be kept clean from
> > user-added stuff, so we don't get name collisions
> > with existing code if future revisions of the API
> > adds new properties. User code-added properties
> > should go into a separate collection. I'm writing
> > "env" here, but maybe that is too overloaded. The
> > Java world uses "attributes".
>
> Why shouldn't users add stuff to the top level? Why
> would there be less chances of collisions in a sub-
> object vs the root? If anything we should be trying
> to reserve room for user information at the top level.
Daniel Friesen wrote:
> Kris Zyp wrote:
> > [...]
> >
> Might this be something to do with Level 1 objects
> implemented in a way that level 0 code is able to work
> with them?
> It's easy to have an .x = {} property on one of those,
> but perhaps not as easy if the top level contains
> unexpected things.
Dean Landolt wrote:
> What's the problem with the top level containing
> unexpected things? It's how it's designed now, and
> seems to work fine for all the other *SGIs. That's the
> point of requiring keys -- everything else is added by
> the implementation or user. This should be irrelevant
> between Level 0 and N -- it's not something that has
> to be specified.
My reasoning here is three-fold, and based on the
following assumptions (but maybe they are broken, please
comment):
1) Level 1 compatible with Level 0
Like Daniel says, I interpreted earlier discussion as
Level 1 should be a strict superset of Level 0, so a
"Level 0 middleware" could use a Level 1 request object
without noticing the difference.
This means we cannot use different naming schemes or
structures in Level 0 and Level 1. Specifically, our
decision about if the <handler function parameter> is
a request object or an environment variable list should
apply to both Level 0 and Level 1.
Also, as Level 1 would have more properties on the root
level, these could collide with Level 0 middleware that
add their own root-level properties with conflicting
names.
2) Separating container-added data from user-added data
With my proposal everything added by user code or user
configuration is put in a separate collection, and the
container "owns" the root of the data structure. I also
include data set by middleware in the "user data" term,
as this is a result of configuring the container with
software not active "off the shelf" in the container.
In itself, this principle is just about staying
organized, but for other features this can make a
difference, as in (3).
3) Being able to wrap requests in a deterministic way
Going forward, adding more semantics to the request and
response objects, I could envision starting to use
data freezing and immutable objects. Something along
the lines of that an incoming request object is frozen
and cannot have f ex its headers changed. If a
middleware wants to change headers it uses a platform
mechanism to wrap/extend/replace the request object
with one that inherits all values but is writable.
Changing this "new" object doesn't affect the caller's
immutable version, and the new object is writable until
it is passed on to the next level, when it becomes
immutable.
Making the new writable request could be as simple as:
var writeableReq = cloneRequest(immutableReq);
but I'm not suggesting any specific pattern here.
Though, to be able to wrap/extend/replace a request in
a deterministic way, the container needs to clone the
data itself "owns" according to its own algorithms, and
then probably just do a plain copy of user data to the
new object. With my proposal this means simply copying
the user data collection, which solely consists of user
data. With a more free principle it would be necessary
to recurse the whole object, having to know what
container-defined props to exclude from the copy.
An alternative way of solving this would be to put all
container-managed properties in its own namespace, such
as in:
{
request: {
requestMethod
headers: {...}
...
}
jsgi: {
...
}
...
}
so that the only container-managed root-level properties
are request and jsgi (and middleware is forbidden to
augment them).
Yet another way (taking the level 0/1 discussion above
into account) is to provide the two projections in
parallel:
{
level0: {
requestMethod
serverProtocol
headers: {"CONTENT-TYPE": ...}
...
}
level1: {
method
scheme
headers: {"Content-Type": ...}
...
}
jsgi: {
...
}
...
}
though personally I'm no fan of this.
Again, if these assumptions are wrong, or not of primary
interest to JSGI, then I have no problem with using the
root as a general container per se.
Best regards
Mike
On Sep 10, 2009, at 4:16 PM, Mike Wilson wrote:
Dean Landolt wrote:
Request Environment
It sounds like most people prefer hash namespacing in the env, but Tom, as an implementer, would need to be on board. However he did propose headers in their own hash -- so it may not be too presumptuous to put jsgi keys in their own hash, like so:
{
headers: {
ACCEPT: ...
...
},
jsgi: {
version: ...
input: ...
errors: ...
...
},
REQUEST_METHOD: ...
...
}Comments:1) Main direction / principleA critical question on the direction of the work is if the designed data structure is supposed to mirror a CGI environment variable structure, or a request object. I prefer the latter. The former implies uppercased stuff in a flat list, and my interpretation is that most people wants to move away from that. The following comments will be in the direction of a minimal request object. It also provides symmetry with the response object (or should that otherwise be renamed output environment?).The intention of the two "levels" was to keep level 0 as a simple gateway interface, and level 1 can have the additional things you would expect from a "request object".
2) Camel caseMost people voted for camel-case properties wholesale (apart from headers) so REQUEST_METHOD should be requestMethod, or maybe just method.If we go the camel case route I would prefer a straight mapping from the CGI-ish names to camelCase. I still believe there's value in using a well understood naming convention for this sort of thing. So "requestMethod" not "method".
5) HeadersThis seems to be mostly agreed, but if doing case shifting I would propose lowercase instead of uppercase as the latter may cause expectations that dashes should also be converted to underscores a la CGI (which they shouldn't).I don't really have an opinion. Are there any other precedents for this besides CGI?
7) URL propertiesThe request should probably contain data about the full URL. This can be done according to three different principles; (a) URL, (b) HTTP spec, or (c) CGI variable names:http://abc.org:80 /basepath /funcpath /extrapath ?p=1a) scheme host port path path path queryb) scheme host port requestUri requestUri requestUri queryc) https=on host port scriptName scriptName pathInfo queryStrc) requestUri requestUri requestUriTo keep things minimal, it would probably be good to choose one main principle, and then maybe fill in a few missing pieces. (If going with CGI then scriptName shouldn't be used for the server+mount path.)What's everybody's opinion here?C. See my response to #2.
9) Mount pathRelated to the URL properties; should there be properties on the request that divide the path into where the application is mounted and extra pathInfo, or should there just be the total pathAbsolutely. In many cases SCRIPT_NAME may start out empty and routing middleware will split PATH_INFO apart for downstream apps. It's critical for things like URLMap middleware.
We could invent another way of doing this, but why?
On Thu, Sep 10, 2009 at 7:16 PM, Mike Wilson <mik...@hotmail.com> wrote:
1) Main direction / principleA critical question on the direction of the work is if the designed data structure is supposed to mirror a CGI environment variable structure, or a request object. I prefer the latter. The former implies uppercased stuff in a flat list, and my interpretation is that most people wants to move away from that. The following comments will be in the direction of a minimal request object. It also provides symmetry with the response object (or should that otherwise be renamed output environment?).
Yes, I agree and understand that most people would prefer more of a request object (including myself). But Level 0 was intended to be a compromise -- a bridge between the current JSGI (that yes, resembles CGI, but hopefully without the warts you've mentioned). Tom's idea was that all of this request object stuff could easily fit into a Level 1 spec, but the work to define that spec is a long time coming, and Level 0 would mean everything that works today stays.
Of course if Kris is on board with many of these recommendations, that's one half of the JSGI implementers, a good way to the kind of buy-in that'd be needed to implement the kind of request obj you're suggesting. But if we can't the rest of the way with buy-in, Level 0 makes a very good staging area.
2) Camel caseMost people voted for camel-case properties wholesale (apart from headers) so REQUEST_METHOD should be requestMethod, or maybe just method.
Agreed -- if we agree to go that route with JSGI-proper (meaning, no Level 0/1) I'd say we might as well stick as close as possible to something like java's servlet interface.
9) Mount pathRelated to the URL properties; should there be properties on the request that divide the path into where the application is mounted and extra pathInfo, or should there just be the total path?
We certainly need the total, undecoded path. But as Tom noted, it's up to middleware to molest the path and script name stuff.
Response
[...] The only open issue is the header hash case-sensitivity. I firmly believe we have to standardize on a Level 0 case to aid interop between Level 0 middlewares (Level 1 can fix this issue with a case-insensitive hash but if left unspecified it will cause problems at Level 0).
Thus I would suggest that JSGI Level 0 specify that response hash keys SHOULD be set as uppercase. In addition, should a non-conforming middleware set a mixed-case key and a corresponding uppercase key exists, the uppercase key SHOULD win. (it can be left up to the implementation whether to respect non-colliding mixed-case keys at all).To me, this is the worst option as it will force developers to mangle their headers to have a decent chance getting it output.
Please explain what you mean by mangle. I don't think we have the same defintion. Headers are case insensitive -- case is irrelevant. I'm with you on the mangling of hyphens and underscores, but we need case consistency somehow -- and rather than forcefully specifying a case-insensitive hash, something like Level 0 could just specify a case.
This means we cannot use different naming schemes or
structures in Level 0 and Level 1. Specifically, our
decision about if the <handler function parameter> is
a request object or an environment variable list should
apply to both Level 0 and Level 1.
Also, as Level 1 would have more properties on the root
level, these could collide with Level 0 middleware that
add their own root-level properties with conflicting
names.
2) Separating container-added data from user-added data
With my proposal everything added by user code or user
configuration is put in a separate collection, and the
container "owns" the root of the data structure. I also
include data set by middleware in the "user data" term,
as this is a result of configuring the container with
software not active "off the shelf" in the container.
In itself, this principle is just about staying
organized, but for other features this can make a
difference, as in (3).
3) Being able to wrap requests in a deterministic way
Going forward, adding more semantics to the request and
response objects, I could envision starting to use
data freezing and immutable objects. Something along
the lines of that an incoming request object is frozen
and cannot have f ex its headers changed. If a
middleware wants to change headers it uses a platform
mechanism to wrap/extend/replace the request object
with one that inherits all values but is writable.
Changing this "new" object doesn't affect the caller's
immutable version, and the new object is writable until
it is passed on to the next level, when it becomes
immutable.
Yet another way (taking the level 0/1 discussion above
into account) is to provide the two projections in
parallel:
{
level0: {
requestMethod
serverProtocol
headers: {"CONTENT-TYPE": ...}
...
}
level1: {
method
scheme
headers: {"Content-Type": ...}
...
}
jsgi: {
...
}
...
}
though personally I'm no fan of this.
Again, if these assumptions are wrong, or not of primary
interest to JSGI, then I have no problem with using the
root as a general container per se.
Dean Landolt wrote:
On Thu, Sep 10, 2009 at 7:16 PM, Mike Wilson <mik...@hotmail.com> wrote:
1) Main direction / principleA critical question on the direction of the work is if the designed data structure is supposed to mirror a CGI environment variable structure, or a request object. I prefer the latter. The former implies uppercased stuff in a flat list, and my interpretation is that most people wants to move away from that. The following comments will be in the direction of a minimal request object. It also provides symmetry with the response object (or should that otherwise be renamed output environment?).
Yes, I agree and understand that most people would prefer more of a request object (including myself). But Level 0 was intended to be a compromise -- a bridge between the current JSGI (that yes, resembles CGI, but hopefully without the warts you've mentioned). Tom's idea was that all of this request object stuff could easily fit into a Level 1 spec, but the work to define that spec is a long time coming, and Level 0 would mean everything that works today stays.
Of course if Kris is on board with many of these recommendations, that's one half of the JSGI implementers, a good way to the kind of buy-in that'd be needed to implement the kind of request obj you're suggesting. But if we can't the rest of the way with buy-in, Level 0 makes a very good staging area.What I am attempting to do (though maybe it isn't showing ;-) is to define a Level 0 request object which is as simple as possible, but builds a good ground for an extended Level 1 request object.
I've discussed the reasons for having a Level 0 request object, and not an "environment" in the spirit of current JSGI, in a mail I just posted. If my assumptions there are not valid, it could probably make sense to stay more on the current API for Level 0, as you suggest.2) Camel caseMost people voted for camel-case properties wholesale (apart from headers) so REQUEST_METHOD should be requestMethod, or maybe just method.
Agreed -- if we agree to go that route with JSGI-proper (meaning, no Level 0/1) I'd say we might as well stick as close as possible to something like java's servlet interface.Personally, I would like to have requestMethod if requestURI is also included, as both point to names in the HTTP spec. If only one of them makes it, I'm less concerned about keeping the "request" prefix on the remaining one ;-).
9) Mount pathRelated to the URL properties; should there be properties on the request that divide the path into where the application is mounted and extra pathInfo, or should there just be the total path?
We certainly need the total, undecoded path. But as Tom noted, it's up to middleware to molest the path and script name stuff.Yes, and as mentioned earlier it would be possible to have just the full URL on Level 0. But that does change things from current JSGI.
Response
[...] The only open issue is the header hash case-sensitivity. I firmly believe we have to standardize on a Level 0 case to aid interop between Level 0 middlewares (Level 1 can fix this issue with a case-insensitive hash but if left unspecified it will cause problems at Level 0).
Thus I would suggest that JSGI Level 0 specify that response hash keys SHOULD be set as uppercase. In addition, should a non-conforming middleware set a mixed-case key and a corresponding uppercase key exists, the uppercase key SHOULD win. (it can be left up to the implementation whether to respect non-colliding mixed-case keys at all).To me, this is the worst option as it will force developers to mangle their headers to have a decent chance getting it output.
Please explain what you mean by mangle. I don't think we have the same defintion. Headers are case insensitive -- case is irrelevant. I'm with you on the mangling of hyphens and underscores, but we need case consistency somehow -- and rather than forcefully specifying a case-insensitive hash, something like Level 0 could just specify a case.You're right, that was a sloppy use of "mangle" :-P. What I meant to say is that if we specify it the way you suggested, we will force all Level 0 and Level 1 software to uppercase all headers, and this will result in headers being sent uppercased to clients (there is no way to correctly case correct headers on the way out, as Wes and Daniel has pointed out). Now this is perfectly acceptable as headers are case insensitive, but I bet parts of the userbase would complain about the "ugliness" of uppercasing all headers on the wire.
In theory, Level 1 software could output case-correct headers, but as long as the platform declares a preference for uppercase (giving uppercased headers priority when building the response) I think all software will in practice feel forced to uppercase.
Finishing off with some process: after most bullets have been debated a bit, I can volunteer to summarize the competing suggestions for each bullet, and organize a show of hands. Does that sound good?
On Fri, Sep 11, 2009 at 11:39 AM, Mike Wilson <mik...@hotmail.com> wrote:
Dean Landolt wrote:My reasoning here is three-fold, and based on the
> What's the problem with the top level containing
> unexpected things? It's how it's designed now, and
> seems to work fine for all the other *SGIs. That's the
> point of requiring keys -- everything else is added by
> the implementation or user. This should be irrelevant
> between Level 0 and N -- it's not something that has
> to be specified.
following assumptions (but maybe they are broken, please
comment):
1) Level 1 compatible with Level 0
Like Daniel says, I interpreted earlier discussion as
Level 1 should be a strict superset of Level 0, so a
"Level 0 middleware" could use a Level 1 request object
without noticing the difference.
That's not how I interpreted it -- I interpreted it as a Level 1 request could use a Level 1 request object, or drop into Level 0 if it wanted. In order to be backward compatible Level 1 just needs to avoid changing anything Level 0 specifies and Level 0 middleware will remain happy all the way through the chain.
Also, as Level 1 would have more properties on the root
level, these could collide with Level 0 middleware that
add their own root-level properties with conflicting
names.
I was convinced by this last argument, but then later you unconvinced me -- it looks as though one of your proposals was 'request' as top level env key with all the requisite usefulness of Level 1. I'm picturing this Level 1 "request" object just acting as a proxy to all the junk Level 0 puts in the env. If that's what you're thinking too, I think that would be ideal. I don't care where this Level 0 stuff goes, but the most compelling argument for why it should be nested falls away when you think of Level 1 as the "request" object key (which could be "reserved" by a Level 0 spec).
What you're proposing is a significant change to the status quo. I think it'd be helpful if Tom and George (and any other heavy jsgi users/devs who haven't spoken up) weighed in.
3) Being able to wrap requests in a deterministic way
Going forward, adding more semantics to the request and
response objects, I could envision starting to use
data freezing and immutable objects. Something along
the lines of that an incoming request object is frozen
and cannot have f ex its headers changed. If a
middleware wants to change headers it uses a platform
mechanism to wrap/extend/replace the request object
with one that inherits all values but is writable.
Changing this "new" object doesn't affect the caller's
immutable version, and the new object is writable until
it is passed on to the next level, when it becomes
immutable.
This makes me uneasy, and I imagine I'm not alone. Middleware owns the request just as much as the app server. When a middleware receives a request, it is the server as far as its child app is concerned (and so on, on down the chain). There's no reason I can think of for a distinction.
On Fri, Sep 11, 2009 at 12:12 PM, Mike Wilson <mik...@hotmail.com> wrote:
Dean Landolt wrote:
We certainly need the total, undecoded path. But as Tom noted, it's up to middleware to molest the path and script name stuff.Yes, and as mentioned earlier it would be possible to have just the full URL on Level 0. But that does change things from current JSGI.
How? The only thing that remains to be specified is whether it should or should not be decoded by the server.
We could certainly define an algorithm for JSGI server implementations to optionally case-normalize headers. That'd be easy and would solve the user problem. As for middleware devs whom want to specify the exact case of any custom headers they set -- well, too bad :) ...but the headers could come out "pretty" quite easily.
Finishing off with some process: after most bullets have been debated a bit, I can volunteer to summarize the competing suggestions for each bullet, and organize a show of hands. Does that sound good?
Sounds great.
JSGI is a CommonJS specification. Jack is a Narwhal implementation of
the JSGI CommonJS specification. It was not always this way, but this
is the target separation.
A word on the development history: Jack came first of all these things
and included a module loader in itself, Narwhal was pared out of Jack
to separate the platform from the server handlers, and then JSGI was
factored out of Jack. Such is programming.
I recommend creating a JSGI/Proposals/B on the wiki. I've not even
been lurking this topic personally, so it would be great to see your
ideas codified so others can evaluate them properly, and so we have
something semi-formal to show hands about. I think boiling the
changes down to the ones you care most about, or making several
proposals with varying levels of change would greatly increase the
likelihood that one of them will be generally appealing.
Kris Kowal
Ditto, I've not been following this thread either. And the Jack->JSGI
thing was partly my fault, I got confused by the Jack app vs the Jack
interface, and thus JCGI was born. Oh and also for those of you who
don't know the addage: "A spec isn't a spec until there is more than
one implementation".
Thanks. I was confused by the JSGI document being hosted and
updated on the Jack site, and CommonJS or ServerJS not being
mentioned on the page.
> I recommend creating a JSGI/Proposals/B on the wiki. I've not even
> been lurking this topic personally, so it would be great to see your
> ideas codified so others can evaluate them properly, and so we have
> something semi-formal to show hands about. I think boiling the
> changes down to the ones you care most about, or making several
> proposals with varying levels of change would greatly increase the
> likelihood that one of them will be generally appealing.
Yes, I was planning to use the wiki. Initially, I've been
trying different ideas to get feedback on the list, and was
planning to document these different alternatives on the
wiki to then base the voting off.
This means that at this stage, the wiki page will specify
alternatives on a number of changes to the JSGI spec, and
not one single complete replacement spec. After the voting
is completed the resulting diffs can be applied to create
a new spec version, preferrably on the CommonJS wiki.
On some subjects there have been a fair amount of discussion
on the list already, and while these subjects will be
visible on the wiki as voting questions, I was not planning
to compile all opinions expressed on the list, but was
assuming that the list discussion would be read for
background.
From yours and Ash's response it seems there might be a
number of people that haven't followed the list but are
still interested in having their say. I hope it will be ok
for these people to read back on the list when necessary.
Best regards
Mike