[Mulgara-general] Mulgara API's

Paul Gearon gearon at ieee.org
Mon Feb 25 00:13:37 UTC 2008


On Feb 23, 2008, at 8:04 PM, Life is hard, and then you die wrote:

<snip/>
>
> 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).

What I really want is to have a single public interface that accepts  
strings and returns data.  This can then be called locally, or wrapped  
in web services, rmi, soap, xml-rpc, or whatever you want.

At the server end, this code will be implemented by passing strings to  
the parser, getting back a Command object.  This object then gets  
given to a Connection into the server (Connections are likely to be  
local, but could be remote in order to handle distributed queries).   
This mechanism will be available to code at the server end so that  
there is no need for Mulgara developers to write TQL strings to access  
internal data.  However, this should not be a public mechanism like it  
is now.

The problem with having a local-only interface with wrappers for web  
services is that it won't work with the command shell.  This is  
because the command shell parses queries to determine where to  
connect. The MySQL client requires you to specify where you're  
connecting (defaulting to localhost), but we try to work it out for  
every command, which requires a parse at the client end for every  
command.

So the options that I see are:
1. A single class like ItqlInterpreterBean that is called by the  
client.  This requires Java at the client and, and restricts the over- 
the-wire protocol behind the class to RMI.  Of course, this is what we  
have now, and I don't like it at all.  Also, this doesn't play well  
with SPARQL.
2 A single public interface that accepts strings.  This works for  
almost everything except the current command line client.  We can  
choose to parse at the client end, just to get the URL of the server,  
then dump the rest of the parsing output and just send the string to  
the server.
3. Again, a single public interface that accepts strings, and a client  
that cannot determine the server to talk to.  Instead it has to be  
told to "connect" to a server.  This reflects what the mysql command  
line client does, but it can break existing systems.
4. The public interface suggested in #2, but keep ItqlInterpreterBean  
for backward compatibility.  This class will use RMI to connect to the  
server, and send parsed structures to the usually "internal"  
mechanism.  This keeps everything working, but moves us much closer to  
the single string-based interface we really want.

Obviously, I've been choosing #4.  I really want to cut down  
interfaces, and I really want to move away from RMI, but I don't want  
to break what currently works via ItqlInterpreterBean.

Why choose an interface which accepts queries as strings?  Well, that  
means clients can be thin, we get wrapped in web services trivially,  
we can leverage all those text based protocols (XML-RPC, SOAP, simple  
HTTP), and we make SPARQL much easier.

> 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?

I think we want similar things, but perhaps I don't explain myself  
clearly.  :-)

Paul



More information about the Mulgara-general mailing list