[jdev] Re: Zeroconf and some thoughts..
pluto at tipic.com
Fri Apr 29 07:53:58 CDT 2005
Even if P2P IM could be interesting, it is something different than XMPP
(according with current specifications, it is basically a client server
protocol; of course everything can be changed).
My opinion is that, more than adding another connection mechanism, it
would be better to improve the services built on it (that is what can
make an xmpp/jabber solution really appealing).
P2P messaging is of interest only in small organizations, where there is
just a single LAN: if you google around, you can find a lot of software
based on the so-hated NETBIOS that meet the goals to be "serverless" and
The lack of a single point of administration in P2P solutions leads
bigger companies to like a client-server approach, as that of XMPP; even
in such a scenario, zeroconf could improve xmpp adoption as I said in my
email (at least according with the opinions of two companies developing
commercial solutions upon jabber, like Jivesoftware and Tipic).
PS. Actually, the zeroconf part is really simple, since you can download
the mDNSRisponder SDK from Apple site and use it in your software. The
hard part is beeing sure that everybody is who he claims to be, since
there isn't an external entity (the server) that assures for that.
Remko Troncon wrote:
>>I think that more than focusing on P2P Zeroconf IM systems (which is
>>something different than XMPP/Jabber), we should look on how we can
>>advertise the presence of a XMPP server (and its services like: allowed
>>logon domains, supported authentication type etc) on the network.
> I personally don't see much use of putting XMPP servers on a local network.
> P2P on the other hand seems a lot more interesting, and requires no server to
> be present at all. Moreover, modifying existing clients to do P2P chatting
> doesn't seem very hard design-wise: messages can be processed as normal,
> and presence should be transformed from the zeroconf way of broadcasting
> presence to an XMPP packet, which should be delivered to the client as
> usual. The zeroconf part is the hardest part to implement.
More information about the JDev