Re: [Qexo-general] XqlServlet

[Per Bothner]

Ivelin Ivanov wrote:
> From: "Per Bothner" <address@hidden>
> (And of course the Apache license is
> > problem, as it may be incompatible with the GPL.)
>
> Have you considered using LGPG  or even Apache license for QEXO?

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

I'm happy with the Kawa license, and see little
reason to change it.  (To clarify: it's isn't GPL; just
GPL as an option.)

Also, Qexo/Kawa is/are GNU projects, which makes a strong
incentive to prefer GNU licenses.

There were some inquiries about using gnu.bytecode with
Apache.  Perhaps I should have permitted the dual-licensing,
since Apache instead ended up using the clumsier and less
efficient BCEL.

In practice I don't think there is a real problem calling
Apcahe code from Qexo/Kawa.

> Maybe the compiled code can still use the JXPath API for bridging to Java.

That takes away the whole point of Qexo:  it compiles directly
to Java bytecodes, when possible using low-leval bytecode
operations.  There is little in JXPath that Kawa does already
do, and do more efficiency, except at the syntax level.  And the
Qexo syntax is of course more general than the JXPath syntax, so
there is no point using the latter.

One thing JXPath may do better (I'm guessing from the documentation)
is that it may cache generated code specific for the class of the
context object.  That would be a bit awkward for Kawa.  My preferred
approach would be to use type declarations at compile time:  More
efficient, and more predictable.

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.
--
        --Per Bothner
address@hidden   http://www.bothner.com/per/