Ok guys... step back a second and think about the situation.
Jabber does not have in band registration to compete with ICQ. You honestly think we looked at that sort of stuff when we created the feature set of Jabber? It is there because we have a distributed server architecture. There is no central location you can go to register a Jabber account because we don't control any other server except for jabber.org.
Part of the goal was to make it easy to run a jabber server. Just configure it (which can be hard enough), and run it. That's it. That's all that is required.
If instead we decided to ax in band registration, and require a web page or some other script or what not for registration, then you just made administrating and setting a server that much more complicated. You are now requiring a web server. To run a Jabber server you must be running a web server? I do not support that at all.
As for Clients becoming simpler by not supporting it, while it may appear that way on the surface, it's not really that hard to support registration. Especially with x:data support. If a server is created that sends out an x:data form, and can parse the results. Then a client, which should be supporting x:data anyway, would have no problems rendering a form for the user to fill out and passing the results back to the server.
All that said. You can disable registration on your Jabber server and do whatever you want to. Setup a web site, manually add users with a script, LDAP, etc... If what you are suggesting is that we as an organization help create some template web pages/CGI, or some scripts, or what not, then I am in full support.
But I am not in support of getting rid of in band registration.
Bart van Bragt wrote:
Justin Karneges wrote:
Realistically, it is not horrible, and I'm guessing Jabber only has it to compete with ICQ (the only legacy system that also has in-band registration, AFAIK), but it does put extra effort on the client and server developers. If we axe in-band registration, we can shift the effort to the administrators, who can develop pretty websites that guide the user along. This would also simplify client development, as there would be less of a need for new user wizards, explanation of what a JID is, etc, as the pretty website would take care of it.
+1 !
Users really need a bit more guidance, preferably in their mother tongue. IMO a website on the public servers would be great and it is also in concordance with the 'simple client, complex server'-paradigm.
-- Ryan Eatmon [EMAIL PROTECTED]
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
