[Mulgara-general] Mulgara API's

[Paul Gearon]

On Fri, Feb 22, 2008 at 3:51 PM, Alex Hall <alexhall at revelytix.com> wrote:
>  That's certainly a step in the right direction.  I remember a big
>  concern from a couple of years ago being that if you referenced model
>  URI's from client code, other models, etc. then those references would
>  no longer work if you moved the server to a new location.  Now you only
>  have to remember the location in one place, where you create the
>  connection, and the rest of your code can be blissfully unaware of where
>  the server is actually running.

Exactly.  That was my goal.

Of course, that left the question about backward compatibility.
Thinking about it, I realized that if I were in a situation where I
wanted the query to give me the connection information (such as for
the command prompt), then it would be better to get this from the the
static parsed structure AFTER parsing (and not *during* the parsing),
and to establish the connection then.  This stays with the new
connection design, and yet it still looks the same to the user.

>  The next question is, how to get the
>  following code working:
>
<snip/>

(BTW, I'll be using the word "graph" instead of "model" in the
following, since we're supposed to be changing over to that
terminology)

>  What I'm guessing will happen right now is that server1 will not
>  recognize "bar:baz" as an internal model, and will pass the second
>  constraint to the remote resolver, which will try to use the protocol
>  and authority to locate the remote server.  Since this particular URI
>  doesn't have those parts, it will not be able to resolve that
>  constraint.  You would need some sort of directory service or other
>  discovery mechanism to answer that query.

We ARE planning on creating a directory service, but in this case it
doesn't matter.

Once you are at a server asking for a graph, then the system graph
gets looked up, to see if that URI exists, and what type it has.  Only
if this lookup returns nothing does the resolver factory get called.
You just need URIs to get inserted and you're set.

I've just updated my own copy of CreateModelOperation to not check
URIs that are opaque and have no scheme, and the example code all
works fine.  :-)

I'll run all the tests over it, and if everything passes I'll check it
in for you.

<snip/>
>  > For client *code* it is certainly more logic than you want.  But as
>  > soon as I have SPARQL going I'll be documenting how everyone should be
>  > moving to using Connections anyway.  Client code should thereafter
>  > stay away from ItqlInterpreterBean.  This complexity is really to
>  > support the command prompt, which will not be going away.  In the
>  > meantime, it also provides ItqlInterpreterBean functionality to make
>  > it easier to transition.
>
>  I think I'm beginning to understand.  It sounds to me like the main
>  difference is that now each command is responsible for determining the
>  remote URL for any models that it references.

Actually, this was how it used to work.  You'd ask ItqlInterpreter
(called by ItqlInterpreterBean) to parse a string, and as it
discovered URLs it would update it's session, and then it would finish
by executing whatever it parsed.  By the time the "execute" mehod
returned it had updated the internal session, and already completed
the command.

The way it works now is that Command has a method on it called
getServerURI().  This can return null (for commands like "set
autocommit off"), but will usually return the URI of a server, if one
can be determined from the command.  There is no obligation to call
this method (and hopefully you won't).

>  Rather than attempting to
>  maintain the session state from one command to the next,
>  ItqlInterpreterBean now relies on the command to find the connection
>  information.  So if I issue the iTQL command
>
>  "create <rmi://localhost/server1#MyModel>;"
>
>  Then the Create command will examine the URI and determine that this
>  command is for rmi://localhost/server1.  But if I say
>
>  "create <foo:bar:MyModel>;"
>
>  then the Create command will not be able to determine a server URL based
>  on the model URI, and the ItqlInterpreterBean will not be able to
>  execute the command.  Whereas if I was using the Connections API
>  programmatically, I would be able to execute that command on an existing
>  connection with no problem.

Correct.  Actually, to confirm that I knew what I was talking about, I
wrote the test code this afternoon before completing my previous
email.  This confirmed that the client code was doing everything
correctly, and that the server was holding up the process.  It was
while writing this email that I decided to try updating the server
code, and it looks like it has worked (well, it DOES work, and I hope
I didn't break anything else).  :-)

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.

Feel free to ask questions.  I can't promise I have all the answers,
but I'll try.

Paul