You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Andy Seaborne <an...@epimorphics.com> on 2011/03/01 19:30:11 UTC

Re: [jena-dev] TDB concurrency


On 26/02/11 08:47, Danny Ayers wrote:
> [on jena-users@incubator.apache.org now...right place finally]
>
> I've decided on Plan D : do nothing :)
>
> Just for ref, here's my decision process:
>
> The idea was for my Turtle editor app to have an integrated server, so
> any created data could automagically be served over HTTP (this ties in
> with the Semantic Web in a Box angle). One option that appealed to me
> further down the line was to give the app a headless (no Swing) option
> so the same setup could be used to deploy a semweb server. I'll be
> using TDB anyway, and Jetty seems like a natural choice for HTTP
> server.
>
> Plan A : code it up myself
> seems like quite a lot of work, especially given the stuff already
> done by others
>
> Plan B : Fuseki
> I had a poke around the download. I'd assumed it was a just a couple
> of extra classes to glue TDB to Jetty, but there's quite a bit more,
> notably an impressive effort to package everything together to make a
> self-contained package. Cool, but for programmatic integration (e.g.
> using the same Jetty instance to serve HTML docs) this would mean I'd
> have to pull everything apart again. Also not having some kind of auth
> would be a problem.

I'd like to enable that (Fuseki as servlets) but as Fuseki 0.2.0 things 
take a while ... you could rip the servlets out of the code base for 
now.  I presume it's possible to add the fuseki jar as a jar and use it 
as a library.  Not tried it - theory.

	Andy

> Plan C : Apache Clerezza
> http://incubator.apache.org/clerezza/
> Reto pointed me in this direction as it used TDB by default and has a
> concurrency lock available. One very appealing aspect is it has a
> JAX-RS implementation which I've played with before, finding it a
> really intuitive way of hooking up web server wiring.
> But similarly it's not obvious how to just use the bits I want without
> also bringing along a load of clutter (for my specific app). Pulling
> down the svn trunk revealed 109 subpackages (maven-managed) which I
> must admit was a bit offputting.
>
> Plan D : do nothing
> My app will have a HTTP client anyway, I need to be able to GET remote
> stuff, and also the ability to be able to address remote systems via
> SPARQL Update and HTTP PUT/POST would be nice to have (also at some
> point I want to make a little adapter for the Talis Platform, so I can
> post graphs up there).
>
> I'm not sure how it would be done with Clerezza, but a completely
> independent install of Fuseki would offer most of the services I want.
> For the automagic publishing of my local TDB, I'm pretty sure that
> could be achieved by recording a datestamp of operations (i.e. an
> ultra-simple versioning system), so it'd only be necessary to transfer
> what's changed.
>
> Cheers,
> Danny.
>
>