webapp packaging

I was excited to catch up with what you were doing; spent some time 
reading the webapp spec, and also looking at the servlex implementation 
a bit.  I'm trying to see how I could provide a compliant implementation 
that delivers indexed query evaluation (for XQuery/XPath) via lux 
(http://github.com/msokolov/lux).

There seem like two possibilities: one is to implement the webapp spec 
within the database engine, and provide another implementation, parallel 
to servlex.  The other would be to provide a different kind of component 
that could be provided by a webapp container (like servlex) external to 
the database: in this model, lux would just serve as an alternative 
method for evaluating XQuery.

I actually like the second model (because it leverages your existing 
efforts, I don't have to implement the webapp part, and can focus on 
query optimization!), but I have a few questions:

I see there is a generic Component interface in servlex, but there 
doesn't appear to be any mechanism for plugging in an XQuery component 
provider other than Saxon.  Is this something you'd be open to 
supporting in servlex?  I guess it would require some kind of registry, 
and in Java, some kind of convention (like a no-args constructor) to 
enable servlex to instantiate a provider.

There are also some parts of the webapp spec that are a little bit 
confusing to me, mostly I think because it is tied so tightly to the 
packaging spec.

1. I'm not sure I understand the intended usage of response/body/@src - 
is this only for file-based resources, or for resources packaged in an 
EXPath module?  Do you think it would be possible to enable the use of 
other kinds
of locators: for example database uris?

2. Is it necessary to require that the request object be set as the 
context item for the executed component? This might conflict with other 
implementation-specific context.  For example, MarkLogic supplies the 
entire contents of the database as the context, which allows for some 
nice short cuts (you don't have to be putting collection() everywhere), 
and my system, Lux, does this too.  I wonder if we could relax this, 
given that there is already another mechanism for getting the request 
element?

3. The component descriptor only allows selecting modules by namespace, 
and not by path (like the at="" statement in XQuery).  I assume this was 
a conscious design choice, but it does lock the spec very tightly to the
packaging spec.  I would like to be able to support the expath http 
webapp spec, but I'm not sure I want to require that webapps be 
packages. I was thinking of offering people the ability to deploy 
webapps that are exploded as directories on the filesystem, or else in 
the database, without requiring a packaging structure.

I understand there is a goal to provide portable libraries and 
applications, that can be relocated to different root paths.  But 
doesn't the base-uri + import via relative-path already provide a 
sufficient mechanism for this?  I'd be interested to hear the rationale 
for enforcing import only via registered namespace.  I can see where 
this makes sense for libraries (so you can possibly download from a 
central repo, etc), but for applications it seems to make less sense, 
and in practice wouldn't it be convenient to allow for a more local 
override?

-Mike Sokolov

Received on Sunday, 14 April 2013 21:06:42 UTC