В сообщении от Вторник 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 _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
