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

[David Legg]

Paul,

>> Thanks also to Alex for suggesting the problem may be how the hostname
>> is setup on the server and to Ron for giving me the clue how to spot
>> it.  When I tried pinging the server from the server I got 127.0.1.1
>> which is not only wrong... it is very wrong!
>>
>> So... thanks all round.
>>     
>
> So, did that fix it for you?
>   

Yes!

For the benefit of future Ubuntu users listening here's what I did: -

I listed /etc/hosts and noticed two lines as follows:

127.0.0.1   localhost
127.0.1.1   optimus

I then changed the second line to read:

192.168.1.10   optimus

Where 192.168.1.10 is the fixed IP address I have assigned to my server 
and optimus is the hostname of the server.

I then changed to /usr/local/mulgara which is where I keep the Mulgara 
jar files and started up mulgara whilst logged in as root:

  # $JAVA_HOME/bin/java -jar mulgara-2.0.6.jar

I could then successfully run my test RMI based program on another 
remote machine and run a SPARQL query correctly and get the results back.

>> Paul,  I think based on this experience I'm wholly in favour of being
>> able to eventually remotely access the full power of Mulgara through a
>> RESTful web interface.  It is just so much more reliable, easier to
>> setup, easier to protect with a firewall etc.
>>     
>
> HTTP, yes. REST.... I'm not so sure about.
>
> REST requires that a URL always returns the same data. Unfortunately,
> if we have update operations on the database, then the returned data
> can change.

No that's not the case.  If I created a restful URL called 
'http://news.com/news/today' you wouldn't expect to get the same news 
page forever more!

I think what your thinking of is "accessing a URL should have no side 
effects".  In other words if I access the same URL twice it shouldn't 
have any undesired side effects; like paying for your shopping basket twice!

> The main thing missing from the HTTP setup is transactions.

Transactions can be handled in a Restful way too (once you've added 
transaction support of course).  The trick is to treat each transaction 
as a first class object so just as you might PUT a new piece of data or 
GET it back you can create a new transaction with a PUT or DELETE it 
when you have finished.  Effectively you are moving responsibility for 
maintaining state between calls from the server to the client.  If you 
get time ;-) I'd urge you to get a copy of Richardson & Ruby's book 
"RESTful Web Services"  ISBN 0-596-52926-0  It makes a lot of sense 
(after a few readings!).

Regards,
David Legg