[Mulgara-general] Mulgara API's

[Life is hard, and then you die]

On Sun, Feb 24, 2008 at 06:13:37PM -0600, Paul Gearon wrote:
> 
> 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.
[snip]

Great! It sounds like we're in violent agreement, then. :-)

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

Agreed (though I'm not sure what SPARQL's problems are here).

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

Are there systems built around the command-line? Can't you just tell
them "hey, it's a new release, things have changed a bit and you have
to do 'connect' first"? (I'm fairly ignorant of who is currently using
mulgara and how)

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

Ok'ish, but you should be making it clear to folks that
Connection/Command is really internal and should not be used (i.e.
with no guarantees that things won't break or go away randomly on new
releases).

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

Sorry, I was trying to figure out where things were headed from the
changes you were making, and (happily) I got it wrong. Things are
quite clear now.


  Cheers,

  Ronald