stanbol-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From adasal <>
Subject Re: Future of Clerezza and Stanbol
Date Mon, 12 Nov 2012 14:24:47 GMT

(Some points below made by others in interim while composing this.)

Whether or not I become a Stanbol/Clerezza consumer or developer I am at
the moment following the list and learning what I can.

For my own interest what was the solution here?

> The biggest design issue for me was that every graph was loaded into
> memory in bulk. The
> underlying reason for this seemed to be that java.util.Iterator does
> not have a close method, so there is no way of knowing when to release
> resources if an iterator is not used to completion.

Skipping down a bit -

> OSGi cannot do magic and set private fields, the compiled classes do have
> bind and unbind
> methods for the private fields, these methods are added by the maven felix
> scr-plugin.

I can see misunderstanding this. An IoC container would set private fields.
I'm wondering about the OSGi non-OSGi difference of approach in this thread.
Has that contributed (in some way) to the way some of the coding has been

Peter obviously is making some very good points.
I should add that developers generally prefer the ability to configure and
initialise programatically.
In the good (bad) old days Sun/IBM actually thought that the configuration
engineer was a separate bod to the integration and development engineer.
I have never actually come across this in practice.
What I have experienced is the irritation of dealing with external files
for IoC configuration which is a context switch from Java.
There is also the issue of where those files should be found in a
horizontal scale out.
I think that the move to all in code configuration from Spring 2.x to 3.x
and also the JEE environment evidences this.
I honestly don't know enough about OSGi to comment further. I realise it
deals with classpath loading issues and dependency.
But it does seem to me that the code should adopt the conventions now used
by non-OSGi deployables, that is a balance of abstract classes, interfaces
and factory methods.
Again I do not know about the possible role of an IoC container here. It
seems a possibility?

w.r.t. Peter's point about Subversion, Git and single release points this
seems like a helpful approach. Stanbol is mirrored on github, of course, so
does that not fulfil this point?
It seems a good point that as RDF2Go is not very active at the moment there
must be a gap in this area.
On the other hand Stanbol should be able to play nice with Sesame, perhaps
by concentrating on integration with either the repository interfaces or
SAIL - the goal of Stanbol is to be a used tool.

I take Reto's point about the difference between Clerezza and Sesame. So
the plus point about Cleressa is that it is an ideal fit to NoSQL rather
than dedicated triple stores. If I understand, this is an important adjunct
to the RDF stack.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message