[jdev] discovery services

[Julian Missig]

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
>>> straightforward
>>> 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  
> ad-hoc
> setup is unavoidably more like s2s than c2s.  Here is what  
> implementations
> 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  
> either
> workstation might have multiple users.  yes, I think we should be  
> forward
> 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  
should.


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.

Julian