[
Lists Home |
Date Index |
Thread Index
]
Burak Emir wrote:
> But nobody talked about "strings or not" for what happens between client
> and server. .
That's my point -- what happens between an XQJ client (consumer) and an XQuery
engine/server/provider is relevant to the "strings or not" API discussion.
My example used a client and server because that architecture is well-suited to
this division of labor -- one program consuming services provided by another.
(As an alternative, you can embed an XQuery engine in the same process as your
application, but then you might prefer to use an input stream instead of an XQJ
interface to the engine.)
>> The programmer should not be concerned at all with these implementation
choices
Disagree. The architecture for deployment affects design and programming choices
(details below).
> >For single-execution queries, the XQJ client program passes the query string
to
> >the driver for each execution of the query (or the abstract syntax tree
> >alternative).
> >
> >For repetitive, stored queries, we don't pass a string each time so we don't
> >parse the query repetitively. We parse it once, and on subsequent executions
of
> >the query, we pass execution time parameters.
> >
> >
> This does not impose any constraint on how you represent queries and how
> the programmer passes them to the interface.
>
> It rather defines what should happen upon
> "preparedQuery.setArgument(1,foo); "
It doesn't impose a constraint, but the elegance of the "strings or not" choice
is not an overriding concern for recurring queries (parse once, execute many
times).
> >>The benefit of a custom syntax/protocol is that it gives earlier validation.
Agreed, for example doing compile-time type checking with a current schema.
> Sure you (the xquery server implementors) can, but the user who wants to
> validate them without a server cannot. Same for testing, debugging,
> pretty-printing, <insert what="high-level programming activity"
> where="here"/> ...
Testing and debugging of an XQJ program will be quite limited without connecting
to an XQuery engine/server.
> More to the point, should the XQJ API support different implementation choices
or use low-level representations that dictate only one?
It makes sense to offer an alternative to passing strings, but not a replacement
for passing strings.
> what happens between client and server should really not have any influence on
the API.
It does. Compare two scenarios. In the first case, everything is completely
contained on my laptop -- XQJ client, XQuery engine, and a collection of 3000
documents. In the second case, an XQJ client on my laptop connects to an XQuery
server run by a large organization having a collection of millions of documents,
with some documents in concurrent use by hundreds of users.
In the latter case, scalability and security become an issue. The API, and the
formats and protocols for communication between the query client and XQuery
engine, must scale and provide options such as connection pooling, caching query
results, setting query timeouts and so on.
The API must be flexible enough to be effective in either scenario.
> >2. Someone building an XQuery server will often prefer a language-neutral
> >solution for servicing clients. Come one, come all -- Java clients, C#, Perl,
> >whatever.
> >
> It's off topic, but I agree - but then I also think every vendor will
> nevertheless supply his own XQJ implementations for Java (and the Dotnet
> equivalent).
I'm not sure what you mean by vendors supplying XQJ implementations. Most
vendors of XQuery (or SQL/XQuery) servers will offer XQJ drivers and .Net data
providers. There will also be XQJ drivers from ISVs and open source projects.
> > XQuery servers, like HTTP servers, will serve a broader audience if they
employ language-neutral and platform-neutral
> >technologies.
> >
> Sure, but the XQJ API is completely independent from these issues.
Not if altering the API affects the interoperability of data or parameters
passed between the XQJ client (XQuery consumer) and XQuery engine.
Suppose for example, we modified the API so XQuery engines return query results
(XQResultSequence) as a binary stream in Apple .img format. Sure, we can
probably find Linux / Solaris and PC libraries with code for reading .img data,
but is that really a language-neutral and platform-neutral API choice?
APIs are not independent of language-neutral and platform-neutral
considerations.
|
