[Mulgara-general] Mulgara API's

Life is hard, and then you die ronald at innovation.ch
Sun Feb 24 02:04:43 UTC 2008


On Fri, Feb 22, 2008 at 05:03:46PM -0600, Paul Gearon wrote:
[snip]
> And if you're thinking that a client shouldn't be doing the parsing
> for you, then I agree.  I'd love to send strings to the server.  The
> reason for NOT doing this yet is:
> 1) backward compatibility,
> 2) the command line needs to parse the command to know where to send
> it.  (I could always parse at both ends, but since the mechanism is
> already there for executing on the session from a client, then I might
> as well leave it where it is).
> 
> Eventually the server will be accepting strings as well (indeed, I
> NEED this for SPARQL, so it makes sense to open up a similar service
> for TQL).  In that case, the Connection will still be called for each
> command, but now it will be wrapping a Session and not a
> RemoteSession.

And earlier in the "Connection/Command questions" thread on mulgara-dev
(http://mulgara.org/pipermail/mulgara-dev/2008-February/000746.html)
you wrote:
[snip]
> The first reason is that TQL parsing has always been done on the
> client side.  I wasn't changing the transport protocols, just the
> method of using them.  So the current setup where queries are parsed
> by the client has remained unchanged.
> 
> The second reason is because I fully intend to parse at the server
> end, but since the services for this are not up yet the interfaces
> were not done.  The plan here was for a LocalConnection class for
> commands to be executed on.
> 
> A simple example is to accept a simple socket connection (say, HTTP),
> parse a query received on this connection into a command, and then
> execute the command on a LocalConnection.  The results then go back
> out the socket.  Once we have this done, then multiple commands should
> become easy.

My problem with this is that it's looking like you'll end up with at
least two different API's depending on whether you use a local
(embedded) connection, rmi, or (say) http. From a client/app
perspective I want a _single_ API for all accesses: a small set of
classes which I can use no matter whether the server is being accessed
via http, rmi, or is embedded. (the current driver.jar and itql.jar
are way too big btw, though granted a bunch of that is 3rd-party
libs).

We've written our own mulgara-client lib to give us exactly this, and
yes, the API is all string based (i.e. itql commands as strings). But
this way all we need to do is change the url from "rmi:..." to
"local:..." to "soap:..." to switch between rmi, embedded, and soap.
I'd rather see something like this in mulgara itself, though.

ItqlInterpreterBean came closest to this (though the separation of the
server-uri, i.e. the Connection concept, was a big sore): we were able
to use it for local, rmi, and even soap (with simple, generated
wrappers). I'm fine with getting rid of ItqlInterpreterBean, but I'd
like a replacement that works the same for all scenarios (from an API
perspective).

Or am I missing something about your plans?


  Cheers,

  Ronald




More information about the Mulgara-general mailing list