[Mulgara-general] Mulgara API's

[Andrae Muys]

On 23/02/2008, at 2:35 AM, Alex Hall wrote:
> Paul Gearon wrote:
>> Importantly, the server you send the command to is checking to see if
>> it knows the graph before handing it on to this resolver.  This means
>> a few things.  Most important is the fact that URIs for a graph need
>> not specify protocol, location, or service.  This is all done when  
>> you
>> establish a connection.  The URI becomes just a label for a graph.
>> (However, it is still possible to use a graph URL to find the server,
>> but this is for backward compatibility).
>
> This seems to imply that graph URL's and URI's have been  
> disambiguated.
>   Back when I was last working with this software, every graph URI was
> also a URL using the rmi:// protocol (for graphs stored on a Mulgara
> server, that is), and the URI was overloaded to be both a label and a
> locator.  Is this no longer the case?

Well they have been disambiguated in the mgr-58 branch.   
Unfortunately the fix is still having troubles with Backup and  
Restore, so it can't be merged atm, and I had to put it to one side  
to get the JTA enhancement in.  The code is still there, and is  
almost ready - and if I can find time to figure out why the Backup/ 
Restore operations are broken, it will be in /trunk.

>> (yes, these methods can be avoided by putting all the  
>> functionality in
>> a Connection class, avoiding the callback, but this does not use
>> encapsulation or information hiding, and makes for a monolithic  
>> class,
>> which is always a bad idea.)
>
> Monolithic class, as in DatabaseSession? ;-)

You might be surprised.  DatabaseSession has seen alot of refactoring  
since you last saw it.  There are a couple of functions that could  
still do with cleaning up, but by and large DatabaseSession has  
ceased being the primary target of refactoring :).

Andrae

-- 
Andrae Muys
andrae at netymon.com
Senior RDF/SemanticWeb Consultant
Netymon Pty Ltd