Ralph Meijer wrote: > If so, I would say it introduces needsless overhead for client > development to have to be able to speak HTTP, too, how simple it may > be. What I mean is that you establish a xmlstream with jabber.org, > and throw an <iq/> at it to get the server list via disco, before any > registration or authorisation. The client can then present that list > to the user and let him make a choice.
Most dev environments have HTTP libraries or compnents these days... so adding HTTP-GET capabilities is easy. Not to mention, most clients already support HTTP-GET for basic file transfers also. It would be a lot hard to roll out c2s changes (either pthsock or jadc2s) to all currently deployed servers to allow disco packets to flow through the c2s component before I'm authenticated. This could also allow DoS attacks by requesting some huge number of disco queries w/out ever having to login. I'm +1 on support as many methods as possible to extract this information from. SOAP would be interesting as pointed out in another post for allowing people to write some kind of automated jabber-registration service, etc. I think at the minimum, we should have disco (servers.jabber.org) and HTTP-GET (http://www.jabber.org/serverlist.xml). Other methods can always be added later. my $0.02 pgm. _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
