[Mulgara-general] Mulgara Lite

[Life is hard, and then you die]

On Mon, Sep 08, 2008 at 08:54:48AM -0500, Paul Gearon wrote:
[snip - discussion on why JRDF is being used in Mulgara]
> 
> However, the most important problem was that we had no control over
> the JRDF interfaces. If we wanted Nodes to all respond to particular
> requests, we couldn't do it. As a result, Mulgara code is littered
> with methods that say things like:
>   if (node instanceof URIReference) {
>     doSomething((URIReference)node);
>   } else if (node instanceof BlankNode) {
>     doSomethingElse((BlankNode)node);
>   } else {
>     doSomethingForLiterals((Literal)node);
>   }
> Not being able to update Node also means that we can't treat the
> various types that can be selected in a query (nodes, variables and
> subqueries) as a single type, and instead we pass this sort of thing
> around as Object.  The list goes on.
> 
> As for repackaging JRDF under org.mulgara.... Yes, I would love to do
> this. However, I am quite wary of it, as the JRDF interfaces form part
> of our public API. I believe that making this change would break a lot
> of the code that talks to Mulgara. If there is some way to make this
> happen without hurting all our users, then I'm all for it, but until
> this is addressed I'll leave it "as is" and hope that no one tries to
> use a JRDF jar in the same process space (a much less likely
> possibility).

Hmm, I guess this shows up mostly in the Answer object?

One way could be to declare org.mulgara... versions as implementing
the original jrdf versions, e.g.

  package org.mulgara....;

  public class Literal implements org.jrdf.graph.Literal, ...
  

However, this would still break for folks using the JRDFSession
interface (is anybody still using that?).


  Cheers,

  Ronald