Happy New Year!
Sorry for being largely off-air at the end of last year and this last
week.
I've finally managed, I believe, to get persistence working in a more
intuitive way within QSAC. Now, SACs are created as persistent by
default, and are resurrected when a SAC is restarted. Let me know if
the result isn't as usable as I think it is.
We should get back our iteration rhythm -- we were doing quite well
for a while last term.
See you,
Norman
--
Norman Gray : http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester
I presume this still requires Java 1.6? If so I'll move the test tomcat
onto 1.6 and see if it still works :-0
> We should get back our iteration rhythm -- we were doing quite well
> for a while last term.
Yes, I've been a bit sluggish of late too, sorry.
I went round and round in circles on the subject of a more
object-oriented API supporting Jena, in particular the issue of where
state was being maintained (at the SAC vs at the client) and how
consistency could be assured. In the end I decided that I was trying
to solve the wrong problem, and that trying to be more "Java-y" in
wrapping a simple restful interface with a stateful set of Java classes
was causing more problems than it solved.
I'm now simply (or should I say "simply", being Jena) bolting in some
methods to return RDF metadata/data in the form of a Jena Resource.
At some point, if need be, we can change those interfaces to use a more
abstract "SkuaResource", of which a "JenaResource" could be an instance -
but I thought it better at this stage to make basic Jena resources
available directly in order to discover which Resource methods are
actually needed/useful.
Cheers,
Kona
--
Kona Andrews k...@roe.ac.uk
AstroGrid Project http://www.astrogrid.org
IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJ
On 2009 Jan 12, at 11:30, Kona Andrews wrote:
>> I've finally managed, I believe, to get persistence working in a more
>> intuitive way within QSAC. Now, SACs are created as persistent by
>> default, and are resurrected when a SAC is restarted. Let me know if
>> the result isn't as usable as I think it is.
>
> I presume this still requires Java 1.6? If so I'll move the test
> tomcat
> onto 1.6 and see if it still works :-0
Ah yes, it does (because the persistence framework TDB does). The
standalone QSAC release works without Tomcat, though, so that's an
alternative.
>> I went round and round in circles on the subject of a more
> object-oriented API supporting Jena, in particular the issue of where
> state was being maintained (at the SAC vs at the client) and how
> consistency could be assured. In the end I decided that I was trying
> to solve the wrong problem, and that trying to be more "Java-y" in
> wrapping a simple restful interface with a stateful set of Java
> classes
> was causing more problems than it solved.
Yes -- I think the problem is that the state _is_ being maintained
entirely at the server end, which means that an O-O client kit can
easily end up feeling weird. A slightly tricky design problem, but in
the end probably a matter of taste.
All the best,