Skip to main content

Call for help on creating V3 of the Xmpp Resource Adaptor

2 replies [Last post]
eduardomartins
Offline
Joined: 2005-10-10

I know that some people are using the current XMPP Resource Adaptor and I know there are other implementations of the same resource adaptor for SLEE (OpenCloud?), what I would like to see is at least a normalized Resource Adaptor Type. For that we (I'm counting on other interested besides me) need to reach an agreement on:

- Events - I really don't like to have the RA Type binded to Smack API so we need to wrap xmpp stanzas. Should we go for the core message, presence and iq only or should we go further in the last one and implement discover info, etc iq extensions?

- Sbb Interface - Well, there is much interest in creating Server connections so this should be updated too. I like how this component is done today but I'm open to new ideas.

- Activities - There is no real activity object in the current Resource Adaptor. Maybe the right choice will be to use the connection so sbb send replies directly from the ACI recieved instead of the sbb ra interface. What's your idea?

- High Availability - This doesn't exist in Mobicents today but lets make it ready for when that day comes. How should HA be implemented on the Xmpp connection which is TCP and may be secured. How one node can continue the work on a connection that was binded to another node that failed? What about the activities?

- API - Jive Software's interest in including my component code in Smack is unknown so far, they haven't contact me for a while since the first emails exchanged. We also need a Server connection code. Should we go for a branched and lighter version? Should we consider another API?

I hope that this time someone can help, I have a lot of work to do at PTI and this will be mostly done in my spare time.

Regards,

Eduardo Martins
PT Inovação

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ivelin
Offline
Joined: 2003-07-13

> - Events - I really don't like to have the RA Type
> binded to Smack API so we need to wrap xmpp stanzas.
> Should we go for the core message, presence and iq
> only or should we go further in the last one and
> implement discover info, etc iq extensions?

My take is to start with the core events and try to get buy in from at least another vendor to standardize an initial XMPP RA Type. You can use net.java.slee.* naming convention for the RA type and a wiki white board similar to the one for the new SIP RA Type 1.2.

> - Activities - There is no real activity object in
> the current Resource Adaptor. Maybe the right choice
> will be to use the connection so sbb send replies
> directly from the ACI recieved instead of the sbb ra
> interface. What's your idea?

Can you elaborate. Maybe use pseudo code.

>
> - High Availability - This doesn't exist in Mobicents
> today but lets make it ready for when that day comes.
> How should HA be implemented on the Xmpp connection
> which is TCP and may be secured. How one node can
> continue the work on a connection that was binded to
> another node that failed? What about the activities?

RA state and SBB state can be fault tolerant using similar replicated caching mechanism that Mobicents already applied for CMP fields, service state and profiles.
See the SIP failover example:
http://wiki.java.net/bin/view/Communications/MobicentsHADemo

ivelin
Offline
Joined: 2003-07-13

> - API - Jive Software's interest in including my
> component code in Smack is unknown so far, they
> haven't contact me for a while since the first emails
> exchanged. We also need a Server connection code.
> Should we go for a branched and lighter version?
> Should we consider another API?

I am not aware of another open source Java API that is readily available. Since the Jive team lost interest in incorporating your contributions to their code base I would suggest at this point to branch off and commit the branched source tree under the xmpp ra source. As soon as that happens, make the announcement on the Jive forum to notify the people who were interested in helping:
http://www.jivesoftware.org/community/message.jspa?messageID=115712#115712

Maybe we can gather sufficient community traction to add jingle support.