On Sat, Nov 7, 2009 at 12:32 PM, Jacob Jay <ja...@verse.org> wrote:
>> My point was that I think it would be handy if wsapi could allow
>> different request parsers. For example, I don't think ?foo[bar]=1
>> would be converted to a table. What about ?foo.bar=1, ?foo[] = 1 or
>> even ?foo[1]=1
>> I'd like to have a way to change the default behaviour. It might
>> already be possible though, I didn't check...
>
>
> I believe a non-standard parsing behaviour should be handled by an
> application itself (i.e. in the application developers code) not WSAPI which
> is providing common ground between the HTTP server and language. The HTTP
> standard behaviours are ?name=value&etc (table) or ?value+value+value+etc
> (array) and WSAPI providing a table for these is helpful.
Do you have a link to HTTP RFC or something describing this standard way ?
> Anything else can
> be handled by just parsing from wsapi_request.query_string as desired. (A
> function for parsing PHP-encoded queries might be a good addition for the
> Lua package environment, but not WSAPI, or Kepler.)
>
> WSAPI should remain slim to be useful (and understandable). Generic
> non-protocol application behaviours belong as additional layers on top of
> it.
>
> Passing a custom application-specific parsing function is interesting but I
> don't really see the need for this to exist as a hook buried in WSAPI,
> obscuring more functionality that can just as well exist in an app itself.
> Query strings should not really contain information that affects the status
> or routing of a request (that WSAPI handles) and thus should not require
> pre-processing, which as far as I can see would be the only argument for
> having such additional query string parsing done in WSAPI.
>
> Given that Lua is table-oriented, extending this facet to [one of] its web
> development environments would be functionally very nice for developers, but
> if promoted, encoding/serialisation should be Lua-like (bringing up the real
> need for flexible built-in an safe serialisation). Actually the only
> difference between HTTP name=value and Lua would be the delimiter (ampersand
> in place of comma). Arguably nesting could be inferred with flattened
> namespaces, not entirely unlike PHP e.g.:
>
> ?foo.bar=baz or (meh) ?foo['bar']=baz represents foo={bar="baz"}
>
> Regardless all such encodings are ugly and make for very user-unfriendly
> URLs, unless restricted to POST form-data.
Such urls are usually not meant to be friendly.
> I strongly believe it is in
> everyone's best interests that web application URLs should follow RESTful
> principles with query strings (GET or POST) used only for truly dynamic and
> entirely optional variables. I'm not however suggesting that WSAPI enforce
> this, but making it easy to follow good practices is truly helpful. When it
> comes to many jobs, speed of implementation unfortunately means REST must be
> left by the wayside and having full serialisation in HTTP params would
> certainly make development super-speedy.
I fail to see why this would conflict with being able to parse
?foo[bar]... You lost me.
--
Bertrand Mansion
Mamasam
_______________________________________________
Kepler-Project mailing list
Kepler-Project@lists.luaforge.net
http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
http://www.keplerproject.org/
