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. 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. 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.
_______________________________________________
Kepler-Project mailing list
Kepler-Project@lists.luaforge.net
http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
http://www.keplerproject.org/
