[jira] Created: (LABS-119) Implement Roster retrieval and management

Implement Roster retrieval and management
-----------------------------------------

                 Key: LABS-119
                 URL: https://issues.apache.org/jira/browse/LABS-119
             Project: Labs
          Issue Type: New Feature
          Components: Vysper
            Reporter: Bernd Fondermann


Implement the logic specified in RFC3921 chapter 7. The roster is stored on the server for each user, so this includes implementing some sort of persistence mechanism.

--
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: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

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

Gerolf Seitz commented on LABS-119:
-----------------------------------

what kind of persistence mechanism did you think of?
since there's other data to store (eg. registered users), a database might fit in.
next question would be: pure jdbc? ibatis? openjpa?

or do you rather want to store data based on files (eg. per jid)?

> Implement Roster retrieval and management
> -----------------------------------------
>
>                 Key: LABS-119
>                 URL: https://issues.apache.org/jira/browse/LABS-119
>             Project: Labs
>          Issue Type: New Feature
>          Components: Vysper
>            Reporter: Bernd Fondermann
>
> Implement the logic specified in RFC3921 chapter 7. The roster is stored on the server for each user, so this includes implementing some sort of persistence mechanism.

--
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: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

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

Bernd Fondermann commented on LABS-119:
---------------------------------------

> what kind of persistence mechanism did you think of?

up until now, I was kind of avoiding this topic. thank you for bringing it onto the table :-)

> 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 HBASE@hadoop.
being lesser tied to some schema, this would provide for more flexibility as other extensions need their own persistence.
but RDB sounds the easiest to start with.

> or do you rather want to store data based on files (eg. per jid)?

rather not. especially since jids can have non-ascii chars. means running into encoding and all kinds of other issues.

> next question would be: pure jdbc? ibatis? openjpa?

ibatis, openjpa, hibernate, something like this.

what do you think?

BTW, should we move this discussion from jira to labs@?

  Bernd

> Implement Roster retrieval and management
> -----------------------------------------
>
>                 Key: LABS-119
>                 URL: https://issues.apache.org/jira/browse/LABS-119
>             Project: Labs
>          Issue Type: New Feature
>          Components: Vysper
>            Reporter: Bernd Fondermann
>
> Implement the logic specified in RFC3921 chapter 7. The roster is stored on the server for each user, so this includes implementing some sort of persistence mechanism.

--
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: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Gerolf Seitz]

Hi,
answers inline...

On Tue, Apr 15, 2008 at 4:53 PM, Bernd Fondermann (JIRA) <jira@...>
wrote:

> > what kind of persistence mechanism did you think of?
>
> up until now, I was kind of avoiding this topic. thank you for bringing it
> onto the table :-)
>

sure, np :)


> > 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
> HBASE@hadoop.
> 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.
i've never used hadoop, so i can't comment on that.


> 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.
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 ;)


>
> > or do you rather want to store data based on files (eg. per jid)?
>
> rather not. especially since jids can have non-ascii chars. means running
> into encoding and all kinds of other issues.
>

right, didn't think of that.


>
> > next question would be: pure jdbc? ibatis? openjpa?
>
> ibatis, openjpa, hibernate, something like this.
>
> what do you think?
>

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 ;)


> BTW, should we move this discussion from jira to labs@?
>

done...

regards,
  Gerolf

[Bernd Fondermann]

Gerolf Seitz wrote:

> On Tue, Apr 15, 2008 at 4:53 PM, Bernd Fondermann (JIRA) <jira@...>
> 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
>> HBASE@hadoop.
>> 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: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Gerolf Seitz]

personally, i don't have experience with JCR, but two fellow wicket
committers
will be releasing a wrapper for the JCR API soon (around May 1st),
basically to get rid of all the checked exceptions, but also with other nice
features :)
so maybe this would be an option...

  Gerolf

On Wed, Apr 16, 2008 at 8:53 AM, Bernd Fondermann <bf_jak@...>
wrote:

> Gerolf Seitz wrote:
>
> > On Tue, Apr 15, 2008 at 4:53 PM, Bernd Fondermann (JIRA) <
> > jira@...>
> > 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
> > > HBASE@hadoop.
> > > 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: labs-unsubscribe@...
> For additional commands, e-mail: labs-help@...
>
>

[Bernd Fondermann-2]

On Wed, Apr 16, 2008 at 9:01 AM, Gerolf Seitz <gerolf.seitz@...> wrote:
> personally, i don't have experience with JCR, but two fellow wicket
>  committers
>  will be releasing a wrapper for the JCR API soon (around May 1st),
>  basically to get rid of all the checked exceptions, but also with other nice
>  features :)
>  so maybe this would be an option...
>
>   Gerolf

we should at least try JCR.

Maybe discuss first the general structure of the repository (nodes and
stuff). How should we put eveything in place?

I will now refresh my JCR memory so I can reply soundly to any ideas
brought up here :-)

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Bernd Fondermann-2]

Just a quick follow up: JCR seems quite right.

  Bernd

On Wed, Apr 16, 2008 at 9:09 AM, Bernd Fondermann
<bernd.fondermann@...> wrote:

> On Wed, Apr 16, 2008 at 9:01 AM, Gerolf Seitz <gerolf.seitz@...> wrote:
>  > personally, i don't have experience with JCR, but two fellow wicket
>  >  committers
>  >  will be releasing a wrapper for the JCR API soon (around May 1st),
>  >  basically to get rid of all the checked exceptions, but also with other nice
>  >  features :)
>  >  so maybe this would be an option...
>  >
>  >   Gerolf
>
>  we should at least try JCR.
>
>  Maybe discuss first the general structure of the repository (nodes and
>  stuff). How should we put eveything in place?
>
>  I will now refresh my JCR memory so I can reply soundly to any ideas
>  brought up here :-)
>
>   Bernd
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Gerolf Seitz]

disclaimer: i have practically no dev-experience with both JCR and XMPP.
feedback of people familiar with JCR is very much appreciated.

so how about something like this:
/content
    /jids
        /<JID> // bare jid
            /roster
                /<JID> [ask] [subscription] [name]
                    /groups
                        /<group>


[ask], [subscription], [name] are considered properties of a roster item.

besides roster management, what else do we have to persist wrt:
-RFC3920
-RFC3921
-any important XEPs with "high" priority
?

  Gerolf

On Wed, Apr 16, 2008 at 9:09 AM, Bernd Fondermann <
bernd.fondermann@...> wrote:

> On Wed, Apr 16, 2008 at 9:01 AM, Gerolf Seitz <gerolf.seitz@...>
> wrote:
> > personally, i don't have experience with JCR, but two fellow wicket
> >  committers
> >  will be releasing a wrapper for the JCR API soon (around May 1st),
> >  basically to get rid of all the checked exceptions, but also with other
> nice
> >  features :)
> >  so maybe this would be an option...
> >
> >   Gerolf
>
> we should at least try JCR.
>
> Maybe discuss first the general structure of the repository (nodes and
> stuff). How should we put eveything in place?
>
> I will now refresh my JCR memory so I can reply soundly to any ideas
> brought up here :-)
>
>  Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@...
> For additional commands, e-mail: labs-help@...
>
>

[robert burrell donkin-2]

On Sat, Apr 19, 2008 at 10:31 AM, Gerolf Seitz <gerolf.seitz@...> wrote:
> disclaimer: i have practically no dev-experience with both JCR and XMPP.
>  feedback of people familiar with JCR is very much appreciated.

http://wiki.apache.org/jackrabbit/DavidsModel
http://www.betaversion.org/~stefano/linotype/news/93/

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Gerolf Seitz]

thx, i actually read those last night ;)
so, any comment on the proposed structure for roster management?

Cheers,
  Gerolf

On Sat, Apr 19, 2008 at 11:42 AM, Robert Burrell Donkin <
robertburrelldonkin@...> wrote:

> On Sat, Apr 19, 2008 at 10:31 AM, Gerolf Seitz <gerolf.seitz@...>
> wrote:
> > disclaimer: i have practically no dev-experience with both JCR and XMPP.
> >  feedback of people familiar with JCR is very much appreciated.
>
> http://wiki.apache.org/jackrabbit/DavidsModel
> http://www.betaversion.org/~stefano/linotype/news/93/<http://www.betaversion.org/%7Estefano/linotype/news/93/>
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@...
> For additional commands, e-mail: labs-help@...
>
>

[Gerolf Seitz]

i came across this little helper: JCROM (http://jcrom.googlecode.com)
a lightweight framework to map objects to JCR nodes.
wdyt?

  Gerolf

On Thu, Apr 17, 2008 at 8:29 AM, Bernd Fondermann <
bernd.fondermann@...> wrote:

> Just a quick follow up: JCR seems quite right.
>
>  Bernd
>
> On Wed, Apr 16, 2008 at 9:09 AM, Bernd Fondermann
> <bernd.fondermann@...> wrote:
> > On Wed, Apr 16, 2008 at 9:01 AM, Gerolf Seitz <gerolf.seitz@...>
> wrote:
> >  > personally, i don't have experience with JCR, but two fellow wicket
> >  >  committers
> >  >  will be releasing a wrapper for the JCR API soon (around May 1st),
> >  >  basically to get rid of all the checked exceptions, but also with
> other nice
> >  >  features :)
> >  >  so maybe this would be an option...
> >  >
> >  >   Gerolf
> >
> >  we should at least try JCR.
> >
> >  Maybe discuss first the general structure of the repository (nodes and
> >  stuff). How should we put eveything in place?
> >
> >  I will now refresh my JCR memory so I can reply soundly to any ideas
> >  brought up here :-)
> >
> >   Bernd
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@...
> For additional commands, e-mail: labs-help@...
>
>

[Bernd Fondermann-2]

On Sat, Apr 19, 2008 at 11:31 AM, Gerolf Seitz <gerolf.seitz@...> wrote:

> disclaimer: i have practically no dev-experience with both JCR and XMPP.
>  feedback of people familiar with JCR is very much appreciated.
>
>  so how about something like this:
>  /content
>     /jids
>         /<JID> // bare jid
>             /roster
>                 /<JID> [ask] [subscription] [name]
>                     /groups
>                         /<group>
>
>
>  [ask], [subscription], [name] are considered properties of a roster item.

Looks good.

>
>  besides roster management, what else do we have to persist wrt:

- overall server persistence

login information (essentially password)
credentials
logs, events, errors, statistics
server configuration

>  -RFC3920
>  -RFC3921
>  -any important XEPs with "high" priority
>  ?

I would not model any persistence for specific XEPs yet.
One requiring persistence is Multi-user chat (XEP-045), another one is
Flexible Offline Message Retrieval (XEP-0013).

--

Concerning the generally structure you started to outline:
an alternative approach to /content/jids/berndf@...
could be using the reverse domain scheme
/content/jids/org/vysper/bernd/... account specific...
/content/jids/org/vysper/gerolf/... account specific...
/content/jids/org/xmpp/gerolf/... account specific...


  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Jukka Zitting]

Hi,

On Sat, Apr 19, 2008 at 12:44 PM, Gerolf Seitz <gerolf.seitz@...> wrote:
> so, any comment on the proposed structure for roster management?

Looks good to me.

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Stefano Bagnara-2]

Bernd Fondermann ha scritto:
> Concerning the generally structure you started to outline:
> an alternative approach to /content/jids/berndf@...
> could be using the reverse domain scheme
> /content/jids/org/vysper/bernd/... account specific...
> /content/jids/org/vysper/gerolf/... account specific...
> /content/jids/org/xmpp/gerolf/... account specific...

I think this is a bad idea.

Let say that one of the paths of "... account specific..." is "roster",
let's also say that we have 2 users: berndf@... and
berndf@... .. you see the problem...

Furthermore I don't see advantages in interpreting the domain part and
reverse it: there is no logic/grouping in that domain, it is simply an
identifier. The issue with too many sibling nodes should be solved by
the JCR implementation and not by your choice of structure IMHO.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Bernd Fondermann-2]

On Mon, Apr 21, 2008 at 10:21 AM, Stefano Bagnara <apache@...> wrote:

> Bernd Fondermann ha scritto:
>
>
> > Concerning the generally structure you started to outline:
> > an alternative approach to /content/jids/berndf@...
> > could be using the reverse domain scheme
> > /content/jids/org/vysper/bernd/... account specific...
> > /content/jids/org/vysper/gerolf/... account specific...
> > /content/jids/org/xmpp/gerolf/... account specific...
> >
>
>  I think this is a bad idea.
>
>  Let say that one of the paths of "... account specific..." is "roster",
> let's also say that we have 2 users: berndf@... and
> berndf@... .. you see the problem...
>
>  Furthermore I don't see advantages in interpreting the domain part and
> reverse it: there is no logic/grouping in that domain, it is simply an
> identifier. The issue with too many sibling nodes should be solved by the
> JCR implementation and not by your choice of structure IMHO.

thanks for the review Stefano.
you are right. Although the domain parts were intended to represent a
tree instead of siblings, it's a bad idea.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...