Norman Rasmussen wrote:
Only having ever implemented room config for the irc client (and even
the using a form that was missing the FORM_TYPE), I can't say much,
but I think I'd prefer to stick with Option #1, i.e. keep the namesas
#roomconfig, and #register. (This just makes more sense).
To be honest any application shouldn't be 'hard-coding' anything
special to do with the FORM_TYPE, and it should rather be parsing the
fields and diplaying them directly assuming a GUI is present. I can't
(off the top of my head) think of a good reason why you'd want to hard
code anything for muc configuration in a GUI app.
From JEP-0068: Thus this JEP enables existing clients to process forms
as they have to this point, but enables JEP authors to specify a
mechanism for non-GUI processors of those forms to determine the
semantic meanings of those forms.
So any existing clients SHOULD not be affected by the change (or not)
of the form namespaces. I also can't think of any muc clients without
a GUI.
I realize this would depart from existing practice, but in my opinion
muc clients should depend on the roomconfig, etc... variables to display
UIs, and not rely on the muc component to provide labels for the current
locale. It is not practical to expect deployers of MUC components to
know in advance which client locales are going to be used.
The model of having the component/server/peer provide labels is fine for
site-specific non-standard forms, but MUC is vastly implemented by many
globally available clients, many of which are available in localizations
that MUC component providers may or may not support.
Regardless of language, client developers may simply also want to have
control over what the user reads in the UI.
Jacques
On a slightly different note: More clients/server implementations are
currently broken because they still change admin and owner list using
the #owner namespace and not the #admin namespace. (Mainly due to
jabberd1.4's muc component I think).
On 2/7/06, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In version 1.17 of JEP-0045 (2004-10-04), the FORM_TYPEs for room
configuration and for user registration requests were modified. This
change was introduced late in the standards process and may not have
been advisable (that's the same day the XMPP RFCs were published,
perhaps I was distracted). I'd like to take a poll of those who have
implemented JEP-0045 (either in a server or in a client). The question
is, which of the following would you prefer:
1. Retain the change made in 1.17, which specifies the following:
room config: http://jabber.org/protocol/muc#roomconfig
registration requests: http://jabber.org/protocol/muc#register
2. Revert to the old FORM_TYPEs:
room config: http://jabber.org/protocol/muc#owner
registration requests: http://jabber.org/protocol/muc#user
Feel free to reply on or off list and I will tabulate the results.
Peter
- -------- Original Message --------
Subject: Re: [Standards-JIG] JEP-0045 namespace changes
Date: Tue, 07 Feb 2006 11:57:15 -0700
From: Peter Saint-Andre <[EMAIL PROTECTED]>
Reply-To: Jabber protocol discussion list <[EMAIL PROTECTED]>
To: Jabber protocol discussion list <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Constantin Nickonov wrote:
Does anyone recall why the room configuration namespace change (ref.
http://www.jabber.org/jeps/jep-0045.html#revs, Version 1.17) was made to
JEP-0045 long after it was an accepted draft. As a result, existing
implementations are in the unenviable position of choosing to keep the
original implementation and fall out of compliance with the JEP (and
thus, other implementations) or making the server-side change and
leaving existing clients out in the cold.
My recommendation would be to revert to the original namespaces, but I'm
sure that this would probably cause similar problems for newer
implementations. Any ideas or suggestions?
I agree that this change was probably unforutunate but I don't remember
why we made it -- perhaps there was a concern about confusion regarding
muc#user and muc#owner but I don't recall.
At this point it seems best to retain the change (MUC service
implementations could look for both the old and the new FORM_TYPEs, be
liberal in what you accept and all that) but I'm not wedded to that.
Perhaps it make sense to poll implementors to see what their preference
is (e.g., I doubt that mu-conference has been brought up to date).
Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFD6PHFNF1RSzyt3NURAiCjAJ9DILqRvWlYT/3vOpVm81pQ4Czw+QCcCelh
l/OdZaD2vG0m3qYyNwsNj4k=
=F8Cp
-----END PGP SIGNATURE-----
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
