Re: webapp packaging

On 14 April 2013 18:10, Michael Sokolov wrote:

  Hi Michael,

> 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.

  Thank you!  And thanks for your comments.  Even though Servlex
has been started 4 years ago, this is the first draft of the
spec, so it has not been reviewed by anyone except myself (as
well as the feedback of users).  So this is definitely a draft
that could benefit from other people's views.

> 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?

  True.  The main reason is that it is hard to isolate the data
model.  So isolating the XSLT/XQuery/XProc processors has not
been a priority, but I tried not to introduce unnecessary
dependency when possible.  Actually I got a look at it in the
past couple of days, and I isolated Saxon and Calabash from the
ServerConfig, it is now a instantiated without any registry
(yet), and passed all the way down using a generic interface:

    https://github.com/fgeorges/servlex/commit/b195ba1a46

  The most interesting part is probably the package "processors":

    https://github.com/fgeorges/servlex/tree/master/servlex/src/java/org/expath/servlex/processors

and it implementation in "processors.saxon".  Note that it is not
completely isolated yet, especially as per the connectors between
the components, but this is promising.  I'd like to remove any
Saxon and Calabash dependency except in processors.saxon".

> 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.

  Interesting.  I thought that aspect was rather well separated,
and not much compared to the rest of the spec (the components are
defined on their own, as well as the functions, as well as the
webapp descriptor, then the packaging part says "use the standard
packaging and add the webapp descriptor as /expath-web.xml").

> 1. I'm not sure I understand the intended usage of
> response/body/@src

  Let's say you want to return an image.  Usually you will setup
a resource element in the webapp descriptor.  But let's say you
want to handle anything more complex, like setting specific extra
HTTP headers.  You can just use a component (say an XQuery
function), but there is no point in actually reading the binary
file in XQuery to return it to the webapp container, it is easier
to simply point to the file and let it connect the HTTP response
straight to the file (and actually it is not even possible for
now to read binary files in XQuery without something like EXPath
Binary).

  The idea is for @src to be relative, to be resolved relatively
to the component (in above case, to the XQuery module).

> Do you think it would be possible to enable the use of other
> kinds of locators: for example database uris?

  Might be.  It might be interesting to say the resolution of
URIs with other scheme is implementation-defined.  Well at first
glance, that's a good idea actually.

> 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.

  Good point.  As you said it is available through $web:input
anyway.  Actually the external variable was a later addition to
cope with a sequence, and I kept the context item, but it is not
necessary anymore then).

> 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.

  There are two cases: libraries (identified by their namespace,
which is required by the XQuery spec) and queries (AKA main
modules).  It is true that for the main module, you must have it
declared in the package descriptor.  Which I've never seen as a
problem, especially when you use XProject (so you use annotations
within the components themselves to assign them import URIs).

  Actually at the beginning, components could be identified by
paths (relative to the directory they were installed into).  I do
not have any strong opinion on this one, and I guess that if you
find it useful, then it just offers another way of architecturing
the applications.  I will see how it could be integrated (or if
you have any proposal, I'd be happy to have a look at it :-P).

> 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.

  The way you deploy/the target of the deployment is not related
to the packaging.  The packaging is defining a standard way of
packaging entire applications as one single self-contained file.
Which is almost required for a professional-quality product (even
if it supports other ways as well, but being able to install a
webapp packaged as one single file, with a standard structure and
meaning, which can be versioned, is really a requirement I think).

> 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?

  That is already what happens when a module imports another one
from the same webapp (it uses a relative import path).  The
public import URI is used within the webapp descriptor when it
declares components, e.g. to associate them to some URL patterns.
That way, the descriptor is independent on the paths, but uses
absolute names.

  But I guess it could use paths relative to the webapp directory
instead.  Initially, instead of a @uri, a component could have a
@file.  So instead of the following:

    <servlet name="user">
       <xslt uri="http://example.org/myapp/users.xsl"/>
       <url pattern="/users/[a-z0-9]+"/>
    </servlet>

which requires the stylesheet to be declared within the package
descriptor, we could have the following (given that the same
stylesheet is at the given path of course):

    <servlet name="user">
       <xslt file="servlets/users.xsl"/>
       <url pattern="/users/[a-z0-9]+"/>
    </servlet>

  Is this what you look for?  I am not sure why I dropped the
support for this actually.

  A project I have in mind for years now, but I wait for the
webapp spec to be stabilized first, is to use annotations to
declare the URL patterns.  Like XProject makes for declaring
component's URI, to generate the package descriptor, but to
declare the URL patterns instead, and to generate the webapp
descriptor.  That is true that in that case, the public import
URIs will probably not be useful at all (even if they would not
harm neither).

  Thank you again for your comments.  I will integrate them when
I have time to do so.  As well as making Servlex extensible with
other processors.  I am leaving for one week on Friday and will
have no access to Internet (I will not even have my laptop), but
I will keep you posted on this.

  In the meantime, keep sending your comments :-)

  Regards,

-- 
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/

Received on Wednesday, 17 April 2013 21:51:52 UTC