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. 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. - 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. 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. Please discuss. Cheers, Sebastian _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
