Gerolf Seitz wrote:
On Tue, Apr 15, 2008 at 4:53 PM, Bernd Fondermann (JIRA) <[EMAIL PROTECTED]>
wrote:
since there's other data to store (eg. registered users), a database
might fit in.
right. a relational DB would be a strong choice. preferably Derby.
another option would be a more semi-structured storage, like for example
[EMAIL PROTECTED]
being lesser tied to some schema, this would provide for more flexibility
as other extensions need their own persistence.
i can't help it but somehow "JCR" popped into my mind while reading this.
+1. great idea.
this also allows for tree-like structures, which are always more painful
in RDB. trees are especially needed for structures supported by the
Service Discovery (XEP-30). JCR seems to fit in very naturally.
do you have any experience with JCR already?
but RDB sounds the easiest to start with.
yes, but i like the idea of a semi-structured storage mechanism better.
since all the messages are xml, using XStream to transform simple POJOs to
xml format would be very convenient. using XStream annotations makes it even
simpler to use.
interesting. I am commenting on the separate thread you started.
so maybe something like a table with:
varchar jid | varchar namespace | varchar (or any supported xml type) data
would be sufficient.
but then again, i'm not really familiar with XMPP. just stumbled over this
project
few days ago ;)
the protocol layer (which would be communicating with the persistence
stuff) is already agnostic of any XML. XML only appears while encoding
or decoding. so I'd personally prefer a more "statically typed" way then
just writing out XML (although favoring a semi-structured storage).
during apachecon we had a discussion about licensing and somebody mentioned
something
like not being able to use hibernate in apache projects since it's (L)GPL
licensed.
i'm not sure if this would impose a problem (personally, i don't really
care).
notice: this should not be yet another licensing discussion ;)
+1. iBatis would be fine for me. But I find the JCR proposal even
slicker (since this is a lab ;-).
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
