On Tue, Jan 14, 2003 at 08:47:48AM -0700, Peter Millard wrote: > 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.
Hmm, ok. But, for this case, only one deployed server would have to be altered: jabber.org. Furthermore, aren't DoS attacks slowed down by karma? If not, than repeatedly trying to register an existing account would cause havoc? > 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 agree. > 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. The disco you mention, is that the same one I propose? Then I'm all for it. I would like having pure jabber solutions. -- Groetjes, Ralphm _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
