[Nepomuk] Refactoring for Soprano 3
Evgeny Egorochkin
phreedom.stdin at gmail.com
Tue Oct 13 19:20:55 CEST 2009
В сообщении от Вторник 13 октября 2009 17:57:58 автор Sebastian Trüg написал:
> 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.
>
> 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.
> - 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.
Backend does sound a lot better than RepositoryFactory :)
Thesaurus says that repository is synonymous to all other storage-related
words so you aren't likely to find a better and meaningful name than this:
cache, depot, repository, stash, stockpile, vault, warehouse.
Or can get creative and say come up with MetaRepository, SuperRepository, or
Storage?
> - FilterRepository and FilterRepositoryConnection replace the current
> FilterModel.
> 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.
This sounds ok. Hope it won't add too much overhead though.
> 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.
If you want it to be black and white, this is the way to go. We need to make
sure this is enough...
-- Evgeny
More information about the Nepomuk
mailing list