[
https://issues.apache.org/jira/browse/LABS-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702750#action_12702750
]
Bernd Fondermann commented on LABS-354:
---------------------------------------
I'm not sure I get what you want to suggest, so I try to rephrase.
Typically, jugding from experiences with JAMES, different people want different
backends. (Not so often: Same people want to mix backends.)
For example, writing a unit test, you typically want some kind of in-memory
storage or mock.
For embedded, you want something easily embeddable, maybe Derby (RDB) or
Jackrabbit (JCR) or even in-memory.
For large scale, people might choose CouchDB (me) or Hadoop (someone mailing me
privately). But these impls do not exist ATM.
Now, programming your extension, say Message Archiving, you don't neccessarily
want to implement any of these backends. You might not even be able to test
them all.
But, as an extension developer, you define an storage agnostic interface
(because you cannot have it storage specific, if you don't want to lock in into
a specific kind of storage). For the sake of having a running extension, you
implement this interface using a JCR backend, or something else you run/have
access to.
If the extension programmer doesn't add the specific backend, somebody else
will, or users are bound to use mix the existing backend with their other
preferred ones they have for other extensions.
Please note that every extension specific JCR storage uses the JcrStorage
class, which provides common JCR routines. So there is re-use. Not every PMI
re-invents the wheel.
Currently, there is only one backend for Vcard-temp, for example. Two for user
authentication and two for roster (JCR and in-memory).
The thing is, storage mechanisms start to diverge in terms of how they work.
Once there was file-based or RDB. For the latter, you need some kind of ORM.
But for modern distributed approaches, which provide a more scalable and
distributable approach, you need different kinds of mapping.
Maybe I try to document this, so it is easier to understand.
> 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
> Assignee: 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]
