[Mulgara-general] Remote loading

[Alex Hall]

Paul Gearon wrote:
> On Fri, Dec 5, 2008 at 2:17 PM, Paul Gearon <gearon at ieee.org> wrote:
> 
>> Yeah, in the past I would get confused too.  The terms "local" and
>> "remote" are from the server's perspective (since that's what is
>> receiving the commands). The guy who made that decision is not with
>> the project anymore. However, I don't want to break existing systems
>> by changing it.
> 
> Doh. I just checked this out, and local/remote is from the client's
> perspective, not the server's. I told you I'm always getting this
> wrong.  :-)
> 
> So "remote" is the default (meaning that the server is supposed to
> pick it up from it's own filesystem). The "local" modifier means that
> the file should be streamed from the client up to the server.  Only
> "local" should result in any RMI calls. Didn't you say you had an RMI
> error when you used "remote"?

Looking back at the original stack trace, the exception is coming from the
distributed resolver.  What I think is happening is that, even though you want
to load data into the remote server (I assume that "optimus" is the hostname of
the remote server), the request is being sent to the local server when you
submit through the WebUI running locally.  The local Mulgara server dutifully
opens up the file and then tries to send its contents across the wire to the
remote server via RMI.  If this operation is intended to work, then there's a
problem, but I don't know that the distributed resolver was designed with that
in mind.

Regardless of what's going on with the distributed resolver, there is no way to
load RDF from a local file *directly* into a remote Mulgara server using the
WebUI.  As Paul says, you need to use the RMI-based TQL client or do something
with the servlet interface.

Regards,
Alex