[Mulgara-dev] Re: Determining the minimal set of classes/jars

[Paul Gearon]

Hi Edwin,

I'm replying to this message on the developers list instead.  (I've  
cc'ed you Edwin, just in case you're not on that list)


On Oct 31, 2007, at 11:40 PM, Edwin Shin wrote:

> Hello all,
>
> I've been updating Trippi (http://trippi.sf.net) to support Mulgara  
> 1.1.0 and I'm struggling with determining the minimal set of classes  
> and/or jars needed to support Mulgara for Trippi. While using  
> mulgara-1.1.0.jar and client-jrdf-base-1.1.0.jar works, that  
> combination weighs in at over 22MB.

Yup.  Not nice.  :-(

Incidentally, while JRDF *will* be coming back, I believe it may have  
been broken with the transaction code updates earlier this year.  You  
will need to check.  Andrae Muys is the guy to ask about if it's  
working, and when it will be coming back.

> Grabbing the 50+ jars out of bin/ and all the third party libraries  
> out of lib/ is not quite what I'm after either as that turns out to  
> be even less lightweight.

I know.  Actually, we don't use many of the classes in some of those  
jars.  Given that we're pulling classes out of those jars and  
including them in our final jar, then we should go to the effort of  
filtering this down to just what we need.  Unfortunately, that's  
likely to be a little time consuming, meaning that people like myself  
won't be getting to it anytime in the foreseeable future.

Maybe this would make a good starting project for any developers who  
ever decide to join?

> A combination of driver-1.1.0.jar plus some of the third-party  
> libraries was closer to what I was hoping for (which is what worked  
> with Kowari and "only" weighed in at around 11MB), but I'm having  
> trouble striking the right combination with Mulgara.
>
> Anyone have some pointers for determining the minimal assembly to  
> support mulgara in both local and remote configurations (no webui)?

The Mulgara-lite target may help.  I have no idea if this target is  
still creating a functional system, but it should make a good starting  
point.

While we've done a number of bug fixes, added some new features, and  
revamped the transaction system, essentially the system is just a  
renaming from Kowari.  So I'm surprised that your previous combination  
is not working.  Can you explain what isn't working now?  Maybe one of  
us who made the changes will recognize what happened and have a fix  
for you?

---

Incidentally, given unlimited time/resources, I'd definitely rebuilt  
the Mulgara framework.  Having an integrated webserver, etc, is  
ludicrous (IMHO).  I'd much rather make the core Mulgara a embedded  
database that accepted query objects, and returned answer objects.   
This can be wrapped in a query parser to accept TQL, SPARQL, and the  
like, making it an embedded database that accepts query strings.  The  
results can then be wrapped in an interface to return XML, etc.

Once all of this is done, then the embedded database can be added as a  
module to a larger framework.  We can then build our own lightweight  
framework to duplicate the one we currently have, and embed the  
database into it.  (This framework would accept RMI and SOAP calls,  
have a web-ui, an contain the full documentation).

The architecture is loosely designed around this structure already,  
but it is much too tightly coupled (I wasn't involved in the decisions  
on this, but I'm guessing it went this way for expediency).  Ideally,  
each level of what I just described would be available in its own JAR  
(eg. a core database JAR, a query interface jar that builds on the  
core, and a framework jar that provides web services, and depends on  
the query interface jar).  Not that I want to distribute the JARs  
split up like this (I love using a single JAR file - big classpaths  
are a PITA).  But being able to build the system into these components  
will enforce a sound architectural approach, and easily enable  
embedding in a variety of ways.

Edwin:  if you need help understanding what is in each of the source  
directories, then please let me know.  I'll document it for you (and  
put it on the Wiki at the same time).

Regards,
Paul Gearon