Re: [Exist-open] Questions & suggestions from a newbie

[Michael B. <mb...@mb...>]

>I am really puzzled by what I
> have seen so far!

Puzzled (= perplexe)? Or maybe ébahi, which would be more encouraging to
established eXist fans...
>
> I really like the HTTP interface which let me do queries using the XSLT
> document() function

You mean the http interface of the native eXist server (rather than sending
http queries to eXist embedded in a servlet wrapper)? I'm not sure on the
current status and functionality of this interface. I used to use it, but in
the features supported it tended to lag behind both the XML-RPC interface
and the functionality available via embedded calls, so I stopped using it.
It's been a while since anybody posted here with an issue related to this
http interface, which suggests that either it's working perfectly or it
isn't now widely used. Don't know which.

>
> I have some questions and suggestions to share:
>
>       * What is the recommended way to shutdown both the eXist server? I
>         had assumed that it would be safe to send a SIGTERM to all the
>         eXist processes, but have provoked a database corruption doing
>         so.

This is not safe with any release version. The snapshot or the CVS is a lot
safer with accidental or brute-force shutdowns (of the server or of the
whole JVM) and gives better, though still to be fully documented, control of
shutdown on command. It also has more elaborate and configurable synching
behaviour, which also helps here.


>  I have also noticed that there is a (undocumented?) shutdown
>         command which can be used from the client interface, but it
>         seems to shut down only the database features, not the HTTP
>         server. I plan to use this command and then kill what's
>         remaining but I am wondering if that's safe and if there isn't a
>         simpler way of shutting the database down.

If you are indeed talking about the inbuilt httpd server, started from
server.sh, then killing server.sh should do the trick, and be perfectly safe
if you have already shut down the database.


>       * What is the impact on performances and robustness of the
>         different backends? Is it faster or slower to use PostgreSQL
>         than the native file system based backend? I would expect the
>         risks of data corruption to be higher with the native file
>         system. Is this the case?

Sorry, but non-native backend support was incomplete (i.e. not fully up to
date with other components) in 0.9.1 and has now been removed from the CVS.
It's history. [Wolfgang, this has cropped up so often recently, might it not
be sensible to flag it up on the site, pending release of 1.0 and its
docs.?]

>       * In a transformation running in the database (through the _xsl
>         HTTP parameter), is there a way to retrieve resources from the
>         database (other than querying the database through HTTP which
>         seems an unecessary overhead)? If I use
>         document("/db/foo/bar.xml"), the transformation tries to
>         retrieve the document on the file system!

Though the _xsl parameter is interesting to play with, I think it's mainly
designed to do a bit of prettifying of the result set, rather than serious
processing. For that, the Cocoon interface gives much more scope (including
the ability to fully parameterise the xslt and indeed to pipeline
transformations).

But I don't see why you are surprised that
document("/db/foo/bar.xml")
tries to retrieve the document from the filesystem. True, the XSLT spec says
this parameter is a URI, and URIs can in theory be all sorts of things, but
exactly how the URI is interpreted is down to the XSLT processor (Xalan in
the case of eXist), and if that processor is passed what looks like a path
to a file on the local filesystem, it will resolve it accordingly. It would
be compatible with the spec for a processor to do other things instead with
the URI, including generating a query to eXist and returning the result, but
that special behaviour would have to be programmed into the XSLT processor,
presumably via an extension mechanism, not performed by eXist itself

>       * It would be very cool if we could ask for the NN last matches of
>         a query (for instance using _start=-NN).
>

Again, the absence of this functionality is a limitation of the native http
interface. Presumably it could be added, but then I imagine the http server
component would somehow have to maintain state across successive queries, or
at least pass back to the client some sort of token that would enable an
ongoing session to be identified and maintained.

Michael Beddow