[jdev] discovery services
julian at jabber.org
Wed Mar 23 08:27:53 CST 2005
On 23 Mar 2005, at 0:31, Justin Karneges wrote:
> On Tuesday 22 March 2005 05:31 pm, Julian Missig wrote:
>> On 22 Mar 2005, at 20:00, Justin Karneges wrote:
>>> Ignoring how iChat may or may not do it, I figure the most
>>> answer would be to have the clients perform the xmpp-core s2s
>>> protocol with
>>> each other. JIDs become user at workstation.
>> Honestly, I prefer iChat's approach. Clients already have client
>> libraries that speak the c2s protocol. You strip out some of the
>> login/auth stuff and just use c2s to one another. That requires a lot
>> less new implementation and allows for a lot more code re-use... at
>> least the way Jabberoo was designed and how I imagine most libraries
>> are designed.
>> Since it's local I don't really see a need for Dialback and its
>> multiple socket connections and all sorts of other server pains that
>> client developers haven't had to be exposed to yet.
> You make a good point, dialback is probably not needed. Perhaps
> the login
> handshake can be done using SASL. However, everything else in an
> setup is unavoidably more like s2s than c2s. Here is what
> need in addition to regular c2s:
> 1) ability to handle incoming TCP connections
That's a feature of the actual implementation, not the protocol used
once the TCP connection is established. This is easy to add to
existing client libraries.
> 2) ability to perform the XMPP stream handshake process in reverse
Simple enough to add in place of the regular auth support.
> 3) stanzas need to indicate both the 'to' and the 'from' (since
> workstation might have multiple users. yes, I think we should be
> thinking here).
Ok, this is pretty silly and makes the problem thousands of times
harder. DNS-SD lends itself to be used as presence broadcasting, but
then you /can't/ use it as presence broadcasting if there are
multiple users connected without making /those/ packets insanely
complicated too. I don't think that's a problem we should be focusing
on at all, because I don't see how it's going to make anything
simpler /or/ better.
I think that for now we should focus on things which DNS-SD has
proven useful for. Multiple users advertising the same service on one
computer is not one of them, and until the DNS-SD people have a good
solution for that (if they care about it at all), I don't think we
I really think it shouldn't be that hard to take a random client
library, hook it up to a DNS-SD and Multicast DNS library, change a
couple of things, and have a working client. The hardest part should
be gutting the presence implementation for use with DNS-SD.
More information about the JDev