[Nepomuk] Refactoring for Soprano 3

[Sebastian Trüg]

On Tuesday 13 October 2009 21:20:12 Max Hofer wrote:
> On Tuesday 13 October 2009 16:57:58 Sebastian Trüg wrote:
> > Hello,
> >
> > Soprano 2 IMHO has a nice design. Backend, Model, and FilterModel suited
> > my needs very well and were nice to use. But now it slowly reaches its
> > limits.
> >
> > With Virtuoso the introduction of transactions become very important. I
> >  tried to stack them on top of Model as you can see in the experimental
> >  branch[1] but the resulting design is flawed and cannot be any different
> >  since we need to stay binary compatible for KDE.
> >
> > Thus, it is time for a redesign and also time for you to state your needs
> >  and ideas.
> >
> > Attached you find a preliminary design in the form of a crude UML
> > diagram. It is based on the sesame2 idea of Respository vs.
> > RespositoryConnection.
> 
> Is there a general overview (description) how sesame2 and the other
>  backends work in the overall concept of Nepomuk and Soprano?

IMHO I wrote a rather nice API documentation which you can look at here:
http://soprano.sourceforge.net/apidox/trunk/index.html
 
> Before I can give my 2 cents I needs to grasp the overall concept ... which
> may take some weeks.

sure, we are in no hurry for the refactoring. First i need to get 2.4 out 
there anyway.

> > A few words of explanation:
> > - Model is split into two classes Repository and RepositoryConnection.
> >   Each RespositoryConnection represents its own transaction object, i.e.
> >   can perform multiple transactions.
> 
> If you say "perform multiple transactions" do you mean those transactions
>  are performed sequentially per connection? Or can they also be processed
>  in parallel/connection?

sequential. parallel transactions are to be done by multiple connections.
 
> > - A Repository can create an arbitrary number of RespositoryConnection
> >   objects.
> > - Backend is now RepositoryFactoy (better name welcome). It is used to
> >   create StorageRepositories which replace StorageModel and have settings
> >   like storage dir and the like.
> > - FilterRepository and FilterRepositoryConnection replace the current
> >   FilterModel.
> 
> Newbie question: on which objects are filter applied? The result of the
>  query?

ATM we have FilterModel which can be stacked on any other Model. The idea is 
that it can do whatever it wants with the data, filter it or change it.
An example is the simple InferenceModel which performs simple inferencing for 
each addStatement and removeStatement call and then forwards the command to 
the underlying model.

Cheers,
Sebastian

> >   A FilterRepository would need to create its own connections which carry
> >   as a member a parent connection created by the parent Repository.
> >
> > This is the basis I would like to start the discussion from.
> > Another issue is inference which I would like to integrate deeper into
> > Soprano. The straight forward design would be to add a flags parameter to
> > method like query() and listStatements() which can for example be
> > EnableInference.
> 
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>