[Mulgara-general] Can't connect to remote Mulgara repository using ConnectionFactory

[David Legg]

> OK. At least the server is up and running. BTW, you can get JSON
> instead if you add a parameter of "out=json":
>
> http://SearchMaster:8080/sparql/?query=select+%24subject+%24predicate+%24object+from+%3Crmi%3A%2F%2FSearchMaster%2Fserver1%23sampledata%3E+where+%7B%24subject+%24predicate+%24object%7D&out=json
>
> Hmmm, now that I'm looking at it again, I'm wondering if "out" is the
> best parameter name to use. Maybe it should be "type=json". Does
> anyone have an opinion here?
>   

Technically I'd say there is already a mechanism for this... it's called 
content negotiation [1] and is commonly handled via the 
content-disposition header [2] ;-)

Failing that... I think type or format is more descriptive than 'out'.

> I thought that the data was all on the Linux server??? I'm confused here.
>   

I suspected that.  The intention is to keep the data on the Linux server 
and develop programs on the Windows machine that access the server.  I 
did also run Mulgara on the windows machine at one point  in an attempt 
to see if the connection problems only occurred in one direction and 
also to check if RMI worked when the server was located on the same 
machine as the client.

To sum up...
1. Running the test client program and Mulgara on the same machine works 
fine over RMI.
2. Running the client on one machine and Mulgara on another over RMI 
fails with a cannot connect failure.

> It's supposed to be easy! I'm frustrated that you're having these
> problems, and would like to help clear them up both for you and for
> others who may run into it.
>   

Thanks.  I think I'll have to go back to basics and check that I can 
make RMI work on this particular network.  The whole point of doing this 
is for future scalability so I want to get it right.

> BTW, would the XML or JSON responses from URLs be suitable
> replacements for what you're trying to do? The TQL interface isn't
> transactional (I should look into that), but it's good for querying.
> I'd suggest that it's preferable to using RMI for doing remote queries
> (which is why I wrote it).
>   

You may have a point.  I'm rapidly going off RMI from a networking point 
of view!  The trouble is that while the vast majority of accesses to the 
server will be queries I will need to do updates too... although I 
suppose I could use the construct keyword for that?  I wonder if the 
overhead of having to re-parse the json or XML results before you can do 
something useful with them exceeds using RMI?

David.


[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
[2] http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx