Re: [Qexo-general] XqlServlet

[Ivelin Ivanov]

----- Original Message -----
From: "Per Bothner" <address@hidden>
To: "Ivelin Ivanov" <address@hidden>
Cc: <address@hidden>
Sent: Wednesday, January 15, 2003 10:52 AM
Subject: Re: [Qexo-general] XqlServlet

> I don't know what LGPG is.  Do you mean LGPL?

Yes. My typo.

...
> The way to go is to (continue) to handle syntaxes such as
> $request/pathInfo, and improve the implementation.
>
> However, JXPath's support for EXPR[INDEX] arrays and collections is
> more difficult.  The problem is that it doesn't make semantic sense.
> In XPath:  EXPR[INDEX][1] is the same as EXPR[INDEX}, assuming INDEX
> evaluates to an integer.  If EXPR is a List of Lists, then you'd
> expect EXPR[INDEX][1] to evaluate to EXPR.get(INDEX).get(1), which
> is something quite different.
>
> In other words: a sequence is fundamentally different from a List,
> and trying to pretend it isn't just causes problems.

I guess JXPath is an attempt to provide a relatively intuitive addressing of
JavaBeans,
while recognizing some semantic weaknesses.


BTW, did you have a chance to look at the XqlServlet errors?
I think that the main problem is that XQuery.eval does not use the
additional information (request/response) available in ServletCallContext.
>From looking at the code it appeared that only the CallContext interface was
used during the evaluation.


One more question.
What API can I use to compile an xql file as a servlet in memory?
I would like to try to do that, instead of having to write the class files
to disk.
One possible problem is that a single xql file may result in multiple
classes.
If I can achieve that, then I will not need to rely on XQuery.eval, and will
be able to implement
an efficient classloading mechanism.
While playing with Kawa I realized that it generates compact class files
pretty fast.
With the cheap RAM these days, it makes little sense to write to disk.



Ivelin




> --
> --Per Bothner
> address@hidden   http://www.bothner.com/per/
>