[Mulgara-general] iTQL trouble

[Paul Gearon]

On Fri, Aug 21, 2009 at 7:26 PM, Gregg Reynolds<dev at mobileink.com> wrote:
> On Fri, Aug 21, 2009 at 5:40 PM, Paul Gearon<gearon at ieee.org> wrote:
>>
>> Looking at it just now, I tried running typing exactly what you have
>> here, and I got no problems. Did you type anything that isn't shown
>> here?
>
> Not that I know of.  I forgot to mention, however, that I'm doing this
> in an mlterm window under cygwin.  Wouldn't surprise me to discover
> I've stumbled over a wart.  I'll try it on the mac this weekend.

That could be, and I saw Tate thinks this has been around for a while.
I don't actually have a Windows machine to work with, so it's a bit
hard for me to test.

>> TQL has nothing to do with ports, so that's not the issue. It does
>> make me wonder what you think you're doing such that you're getting
>> confused here. Can you explain a little more?
>
> Wish I could.  I'm afraid you've got all the info I have: start the
> server with -p 8088 -u 8089, the tutorial page works fine, but not the
> Descriptor Mgmt page nor the querylang jar.

The descriptor could be a port issue. I'll look at it when I have
time.... but that won't be for at least a week. I'm about to go
offline for a bit, while everything I own goes into boxes. I'm not
even sure when the delivery company will show up.... they say it will
be sometime between August 28th and the September 1st. I can do it
after that... but you should ping me to remind me.

>> Well, as I said, ports don't have much to do with what you're
>> discussing, with the exception that descriptors are accessed over HTTP
>> (port 8080 by default). But since everything else you're talking about
>> isn't related to that, then there really isn't any documentation to
>> talk about.
>>
>> One other thought I had was to do with firewalls. It looks like you're
>> using RMI, and the ports for that might not be open.
>
> Could well be.
>
> How would one choose between RMI and something else?  I didn't do
> anything explicit to choose RMI (that I'm aware of); didn't even know
> it was an option.  I confess I don't know much about RMI; I rashly
> assumed this was all TCP sockets, which is why I suspected the ports.
> I assumed the command line interface (and the client APIs) talked to
> the server via a socket interface, but digging further into the code I
> can see I'd better do a little more research before speculating any
> more.  Maybe some documentation will come out of it. ;)

Well the "querylang" client won't be suffering a port problem, so I
suspect Tate was right about it being Cygwin. It may be a console
setting that Java doesn't like.

Mulgara sets up an RMI server to accept clients that connect to it
with an interface called "Session" and issue queries/commands on this
interface. "Sessions" are also served up locally, so other services in
the same JVM can get the same functionality without having to deal
with RMI (but the calling code looks identical). Sessions are created
by an object called a "SessionFactory".

There are 4 main client configurations that connect to Mulgara through
this interface:

1. Anything "embedded" sets up an instance of a SessionFactory and
uses it to get Sessions. For instance, Fedora and Sesame both do this.

2. A default Mulgara instance starts up an HTTP server (Jetty) and
uses a local SessionFactory to give Sessions to several web apps.
These web apps include the WebUI, the SPARQL interface, and
Descriptors.

3. A Tomcat deployment starts Mulgara and then uses RMI to get its
SessionFactory. This factory is then registered in the system
properties for each of the web apps to pick up. The web apps are the
same ones described in #2, but are not being started in Tomcat instead
of an embedded Jetty.

4. A querylang client looks for servers using RMI. It usually uses
graph names to identify the server. So if you select from a graph
named <rmi://somehost.com/server1#graphname> then it will look for an
RMI service at somehost.com, and once it has a remote Session it will
look for a graph with that full name. If you want a graph with a name
like <http://foo.com/data.rdf> then instead use the name
<rmi://somehost.com/server1?graph=http%3A%2F%2Ffoo.com%2Fdata.rdf>.
(Yes, this is messy, but it's all about backwards compatibility).

Note that querylang can only go looking for a server if it can
identify one from the current query. If you say "help" then it has to
do that work locally. In other words, the "help" command doesn't do
any network access at all.

Is this explanation useful? Is it clear? I realize I'm made a lot of
assumptions as I described it, but if I went to first principles then
this email would get REALLY long.

Regards,
Paul Gearon