[Nepomuk] Refactoring for Soprano 3

[Sebastian Trüg]

On Sunday 18 October 2009 09:10:00 Hari krishna Anandhan wrote:
> Hello,
> 
> > 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.
> 
> Based on the uml diagram and your description, I attempt to do a
> design review (as i think that design must be self explanatory without
> reading too many docs)
> 
> I think the name FilterRepository is misleading as it implies that it
> only does filtering. Something more in the lines of ProxyRepository or
> AdapterRepository would be appropriate (I will refer it by that name
> in this mail, to get a feel of it ...)

ProxyRepository sounds like a good idea.
 
> So, lets begin...
> 
> Repository is a generic class, which can be a StorageRepository or a
> ProxyRepository .

or a direct subclass of Repository. There are no restrictions.

> RepositoryFactory must be used to create any repository, may it be a
> StorageRepository or a ProxyRepository .

No, that does not make sense. The only reason for the factory is the plugin-
system. Any other class can be instanciated directly.

> Each created Repository can create a new RepositoryConnection, which
> implements the RDFModel.

yes.

> A ProxyRepository creates a ProxyConnection.

What is the advantage of this? The way I see it ProxyConnection is a 
convenience class that makes it simpler to implement proxies. Imagine you 
simply want to drop some statements in addStatement. Then there is no need to 
reimplement all the other methods. They can simply be forwarded.
If you, however, need to do something really fancy where you need to 
reimplement all of them there is no real need for a proxconnection. There 
might even be some other RespoitoryConnection subclass that is better suited.

Cheers,
Sebastian