Re: [Qexo-general] re: XqlServlet and Communication between XQL scripts

[Ivelin Ivanov]

> Ivelin Ivanov wrote:
> > This patch detects when the CallContext is a ServletCallContext and
treats a
> > non qualified URL as a local servlet path relative to the current xql
> > servlet.
> > For example if the calling xql resides under webapp/rss2html.xql, and it
> > uses
> > document("sample/rssfilter.xql")
> > QEXO will resolve it to something like
> > document("http://localhost:8080/qexo/sample/rssfilter.xql";)
> > assuming that http://localhost:8080/qexo is the base URL for
rss2html.xql.
>
> I'm somewhat unsure to what extent this is needed.  In the servlet
> example at http://www.gnu.org/software/qexo/XQ-Gen-XML.html
> I managed to use relative path ok - however, it's been a while
> since I wrote and tested this code, so I'm a little hazy on exactly
> what is going on in terms of finding the default diretory.
>
> Presumably URLs should be relative to the "web-app", but I'm not
> sure whether they currently are.  I thought they were ...

Before my patch, relative urls were automatically prefixed with "file:"
which didn't do what is expected
in a servlet context. My patch should fix this, but I am not sure how you
would like to handle dependencies.
It think that the servlet package is so small that it is not a significant
difference if you include it in any distribution.

>
> An alternative, as you mention in another message, is to implement
> the two-argument version of document.

I'd like to hear more on this.
Where should I look for the code which initializes and passes the input to a
script,
such that fn:input() will get it. This will allow in a way non-violating the
spec to
define the input as a QEXO specific type. Since the spec leaves input to be
context and implementation specific, QEXO can define input in the servlet
environment as something modeled after the servlet API,
which is easy to work with:

<request>
  <header>
    <accept-language>...
    <connection>...
  </header>
  <parameter>
    <login>someuser</login>
    <email>address@hidden</email>
    <email>address@hidden</email>
  </parameter>
  <attribute>
    <errorMessage>Bad Login</errorMessage>
  </attribute>
  <configuration>
    <test_param>blah</test_param>
  </configuration>
  <session>...
  <document>
    <rootElementOfPostedDocument>...
  </document>
  <cookie>
    <oldVisitor>true</oldVisitor>
  </cookie>
</request>

I am not sure yet, how response headers and cookie manipulation can be
implemented in a clean way.
Maybe, we can also allow the user to stream out a "response" element as part
of the result sequence, which in effect controls the output HTTP headers and
cookies.
If the result sequence starts with a predefined type of element (e.g.
http-response),
QEXO can treat it as something special and which is will not be part of the
output document.

<response>
  <header>
    <content-length>...
  </header>
  <cookie>
    <oldVisitor>true</oldVisitor>
  </cookie>
</response>

>
> (According to the spec, relative URLs are supposed to be relative
> to the document *source*, which to me makes little sense.)

Weird.


>
> I've been on a 3-day trip and so I'm a little behind on various
> things, including my "day job" work.  So it make take a few more
> days before I can really look at your submission.

I see.

Looking forward to hear more from you.


Ivelin