Hi Vincent, Emil and devs, I'm back,
I was seeking about your queries and this is what i've found.
JXTA IM Communication:
- One to One
JXTA IM Roster:
- User built roster (allows to add friends manually)
- Stored locally (metacontact object serialized to a file)
JXTA IM Presence
- Persistent presence only on the buddy list (ping?pong! approach)
JXTA IM Peer Discovery
- It makes a general peer discovery on the start, and save the reached advertisements in local cache. Later searches are resolved locally.
MyJXTA Communication:
- One to one
- One to many (group chats)
MyJXTA Roster:
- Automatically built roster (roster = list of ChatGroup members)
- It's not stored.
MyJXTA Presence
-Presence provided from the Roster plugin. But with a developer note: "it was not the intention of the author to implement a very clever implementation of the typical p2p presence problem". This is not a Persistent Presence implementation. It only checks the group members state once on the logon stage and once again when login out. (uses a ping ping approach too)
About to keep the compatibility with one of them. Nowadays JXTA IM is a dead project: there are no activity in the mailing lists, and asac (the main developer) tells me that the project is discontinued. Then, JXTA IM is a bad candidate.
For the other side MyJXTA look so better. But the presence rusty solution is an important issue. It would be the better candidate comparing both. But the compatibility with MyJXTA may be drives me to a badly implementation. In my opinion the Presence & Roaster solutions that I can implement may be easily better than MyJXTA ones.
WDYT ?
Don't hesitate to reply and give your opinion.
Best regards,
Aimar.
On 5/18/07, *Emil Ivov* < emcho@emcho.com <mailto:emcho@emcho.com>> wrote:
Hello Aimar,
Nice to see you on the list!
In your previous mails on the gsoc mailing list you mentioned two
existing IMP clients using JXTA - J.I.M. and myjxta(2). How do they
handle contact lists? Do they save them locally?
Isn't there a way of storing a roster in the overlay? Doest JXTA
offer a
data storage service that you could use to do this?
If no then we can also store our lists locally. That's what we do anyway
since the meta contact list would store them no matter whether they are
kept on a server or not so that's really not that much of an issue.
> What I would like to know is if this paradigm without friends roster
> fits within what SipComm wants.
It certainly is not a problem in itself. One thing that is very
important for us however is keeping compatibility with existing
software. (such as J.J.M. and myjxta(2) ). I'd personally say that it
would be a good idea to simply choose one of the two clients and
implement support for the protocol it uses in SIP Communicator.
WDYT?
Emil
MeL wrote:
>
> Hi Emil, Vincent and other developers.
>
> I'm Aimar Gonzalez, the student at charge of the JXTA support for
> SipComm. For the one that are not familiarized with JXTA you can
take it
> as a transport layer that allows you to deploy p2p infrastructure
over
> any real network topology. JXTA allows us to work with a p2p network
> were peers and services publish and communicate seamlessly.
>
> As JXTA can be taken as a transport layer I've to found a IM
protocol to
> put over it. I need a protocol that can behave well in a p2p
abstraction.
>
> I've been studding some of them. The problem is that most of them
have
> features that require some type of persistent server. Most common
> example is the user settings, identity register, user roster
management,
> etc.
>
> This collides with the p2p paradigm because it forces us to
centralize
> services over a p2p network, so we loose most of JXTA features. Also
> taking into account that JXTA provides a DHT managed p2p network
which
> is loosely consistent, one cannot rely on centralized permanent
services.
> So my first approach is to delete this kind of services of the IM
> protocol. The result is:
>
> - allows to join the service without previous service.
> - free election of nickname (if it is not already in use)
> - private chats (one to one)
> - public chat rooms (but no persistent)
> - private chat rooms (also not persistent)
> - loosely-consistent users location (you see the presence of
people
> in the same channels as you or you can inquiry presence for known
> nickname, but a presence roster is not maintained).
>
> You may already noticed that this approaches much more a IRC paradigm
> than a MSN/XMPP paradigm. In fact, IRC protocol can be easly
adapted to
> a JXTA transport. Anyway I'm not talking about porting the IRC
spec to
> JXTA but to implement something similar.
>
> What I would like to know is if this paradigm without friends roster
> fits within what SipComm wants. I'm not saying this is the only
approach
> that can be taken but it is the one that fits more naturally
given that
> JXTA doesn't have any IM infrastructure.
> I would really know your opinion and suggestions about this.
Anyway I've
> been told of a course on my university that learn JXTA and implement
> some IM stuff on it. I forward getting some documentation from
there to
> get ideas.
>
> Don't hesitate to reply, and comment the proposal.
>
> Thank you,
>
> Aimar.
---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net
<mailto:dev-unsubscribe@sip-communicator.dev.java.net>
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net
<mailto:dev-help@sip-communicator.dev.java.net>