In the past I used another project to practically use trendy new things like patterns, XML, Swing, etc. Similarly, I'm going to use JRDF for the same purpose. Kowari is a bit too big for things like going over to Java 1.5, IoC, mocking (real unit tests), lock free alogirthms (including B-Trees) and a few other things that I want to try. I'm not sure it's possible to have a system that doesn't have transactions but it would be interesting to find out. So basically this is just to let people know to expect some changes in JRDF.
Practically, it might mean an RDF/XML based pull parser, persistent JRDF, and more interesting APIs. I'm convinced that developing web services is too expensive and may implode under its own weight - so maybe something based on netKernel or a REST based framework would be a good idea. At the moment I'm just using it to see how much I can get out of IntelliJ.
3 comments:
I've started to move over the connection classes that I wrote for Kowari into JRDF. Expect a patch soon with text query-oriented classes. Of course, someone will need to write the query layer ;)
There are really use cases in mind - at least how I think of them. The best examples are how JRDF can be used is in Kowari.
The client-jrdf, content-mp3, content-mbox, content-n3, and content-rio (a port of the RDF/XML parser from RIO).
You can have a browse from:
http://cvs.sourceforge.net/viewcvs.py/kowari/kowari-1.1/src/jar/
I plan to explain how the blank node stuff is supposed to work because that's not entirely obvious.
Look forward to it Tom. Hopefully, I'll be able to put a set amount of hours a week on this and get some traction on it.
Post a Comment