[ 
https://issues.apache.org/jira/browse/LABS-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702677#action_12702677
 ] 

Bernd Fondermann commented on LABS-354:
---------------------------------------

Every Service/Extension which needs storage defines it's own PersistenceManager 
interface (PMI), defining it's operations, but being agnostic about the 
underlying implementation. This is 'vertical', if you want. This is good.

Right now, there are PMIs for user accounts, roster, vcard. Many more will 
come. Many will be for optional extensions.

Currently, there is a JCR storage implementation, implementing every single 
PMI. 

Now, if somebody choses to do an implementation using, let's say, RDB, it 
should be possible to start implementing only one or some of the PMIs there 
are, not every. 

Others may chose to mix different kinds of storage, for performance, testing or 
whatever reasons.

So we need some mechanism to easily plug them together.

This is what this JIRA is all about. I'm currently working on a first impl. I'm 
not using the whiteboard pattern for now, but am open for suggestions.

 As soon as I have something working, I will commit for others to review.

> Create centralized persistence service handling
> -----------------------------------------------
>
>                 Key: LABS-354
>                 URL: https://issues.apache.org/jira/browse/LABS-354
>             Project: Labs
>          Issue Type: Improvement
>          Components: Vysper
>            Reporter: Bernd Fondermann
>
> Different parts/extensions need persistence. These are for example: user 
> accounts, roster, vcard, offline messages, etc.
> Implementations may rely on RDB, Jackrabbit, in-memory or CouchDB technology.
> If one is exchanged for the other, it is currently required to change every 
> persistence service. It would be great to have only one place to change 
> between (for example) in-memory and JCR storage. 
> This central persistence service manager could be implementing the 
> "whiteboard pattern", where implementations don't have to choose a specific 
> implementation, but this is reversed: they announce their availability to a 
> central registry and the appropriate persistence service is provided.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to