RE: JXTA for Application Service Providers

[Michael Oliver <ol...@matrix-media.com>]

James,

You are quite right, JXTA has "Peers" which can be anything from PDA to
Server, TRUE DAT.  However for us, our Servers are communicating already
via JXTA to keep themselves in synch and to monitor status, etc.

What we want to do is take advantage of those pipes and build an IM/Chat,
Presence and File Sharing ability to take advantage of those pipes.

We are not looking for interoperability (YET) of these Users with the
outside worlds of other IM and P2P Networks, i.e. "In House".

Michael Oliver
CTO/Matrix Intermedia
7391 S. Bullrider Ave.
Tucson, AZ 85747
Office (520)574-1150
Cell (518)378-6154


James Higginbotham said:
>> Ok so now the question.  We have almost all of our customers
>> and customer applications delivered via a Web Browser.  We
>> want to add IM/Chat, Presence and File Sharing to our
>> delivered Applications.  We have looked at Jabber and even
>> deployed it successfully for one of our customers....but JXTA
>> seems a better choice for a number of reasons.  We also will
>> have JXTA and PeerGroups already and don't want to add Jabber
>> servers and duplicate and complicate if we can do what we
>> want/need on top of JXTA.
>
> Can you explain a little more about your requirements? JXTA has no
> concept, last I looked, of a user at the protocol level. This makes it
> hard for IM to be done between JXTA apps that are out of your control,
> as presence and unique identification can only be done per
> application/application suite. If you want to enable your users to
> utilize existing IM network infrastructures, you should go for jabber or
> another API. If you want to keep it "in house" then JXTA is an option.
>
> I started using JXTA in May 2001, right after the SDK became available
> and have seen it grow over the years. Hopefully it will do what you want
> it to do now. One thing to keep in mind is that JXTA is a research
> project, nothing more. There is a good group of people working on JXTA,
> but in the end, it has research money and could be pulled at any time.
> This is a risk you will need to take into consideration, just as you
> would any other commercial or open-source library that you may use.
>
> HTH,
> James
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org