[Mulgara-dev] Mulgara Apps

[Gregg Reynolds]

On Fri, Dec 3, 2010 at 12:20 PM, Paul Gearon <gearon at ieee.org> wrote:

> On Fri, Dec 3, 2010 at 9:09 AM, Gregg Reynolds <dev at mobileink.com> wrote:
> > To follow up on my previous note, I propose splitting out "Mulgara Apps"
> > from the kernel and resolvers.  I view mulgara-x.y.z.jar as an
> application
> > that uses the Mulgara kernel.  But currently it is entangled with the
> kernel
> > code (so to speak);
>
> I think I need a clearer picture of what you are defining to be an "App".
>
>

> So what's is an app for you, and where do you want to see a new
> "clean" delineation?
>
> I hope to get a better picture myself this weekend.  I'm thinking of
Mulgara as basically a library that developers use as a component in their
applications, rather than being itself an application.  I know the binary
distro ships as a server app, but it looks to me like the real goal of the
project is to ship a good infrastructure component for developers, and the
app is secondary.  Which doesn't necessarily mean anybody on the dev team
looks at it that way, but it's what it looks like from here.  And it looks
good that way from here.

>From this perspective mulgara-x.y.z.jar looks a lot like a sample
application.  That's no judgement as to its quality, just saying it looks an
assembly of non-mulgara functionality (Jetty, servlet) wrapped around a
Mulgara "kernel".

I guess the language you want to use depends on how you look at the overall
thrust of the Mulgara project.  I'm using "app", "kernel", "backend", etc.
mainly because I'm thinking about how to represent the whole/parts in
documentation in way that is simple and transparent and that harmonizes with
"standard" language about architectures.  I expect my usage will change as I
become more familiar with the system.

"Clean delination" meaning both clearly defined (sounds like it is already)
and clearly documented.


> > Add apps/mulgara-sparql, which is a plain sparql frontend with embedded
> > Jetty and memory/file (store?) resolvers
> > Add apps/mulgara-sparqlet, which is a servlet that can run in any servlet
> > container
>
> The SPARQL frontend is already a servlet that can run in any servlet
> container. Well, that's a broad claim. I can vouch that it runs in
> Jetty and Tomcat.  :-)  It *should* run in anything.
>

Here I'm thinking of the various ways one can implement such a front-end.
 There's the standard, container-agnostic servlet way, but then with e.g.
Jetty one could also implement a plain "handler", which is not a servlet.
 Another possibility is to make Mulgara/SPARQL service available to non-Java
webapps by slapping an
FCGI<http://www.fastcgi.com/devkit/doc/fcgi-java.htm> wrapper
around a standalone server.  Then Mulgara could run directly behind e.g.
nginx, without an embedded http server (but with some means of launching the
indpendent Mulgara process).

I guess this is all part of the documentation I have in mind, which I'll try
to write up this weekend.  There are only so many basic architectural
patterns one can use to implement e.g. a SPARQL service using Mulgara, with
this or that resolver; I'd like to provide at least an overview, and maybe
and example, of each.


> > Ship some demos in a demo dir; these would have more specific
> functionality
> > than apps, e.g. a TODO list app with an embedded RDF triplestore, using
> only
> > the Mulgara API.  Only included in the source distrib.  The purpose is to
> > show developers how to do it, rather than provide real apps.
>
> That's what I started in the tools/ directory (it was a demo that grew
> into some useful tools for my testing). However, that's just
> client-side code. A useful demo would be creating an embedded database
> (a common request).
>

Can you be more specific as to what people are looking for?  E.g., somebody
wants an app the runs a Mulgara DB, but only within the app process space,
and accessed by a Java API?  What sorts of applications?  Or maybe a better
question would be: would do you envision as the ideal embedded DB demo?
 Might be a good project for me.

Thanks,

-Gregg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-dev/attachments/20101203/dec8ced7/attachment.html>