[jdev] MUC implementors poll

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jacques Belissent wrote:
> 
> 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.

For sure. The reason we put this stuff in a registry is so that we have
clear documentation of what the most common fields are (if you want to
use more specialized fields, you're on your own). We hope that because
we've defined the fields, client developers can create localized text
strings for them rather than using the English labels in the JEPs. In
fact, perhaps it would be helpful simply to remove the labels entirely
from the examples. At the very least, each JEP that describes or uses a
FORM_TYPE probably needs to include an Internationalization
Considerations section that talks about localization of the form fields.

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD6/9XNF1RSzyt3NURAs5bAKDaT6FuW6olgVXJDcFlWoWbsAueUQCeKacJ
uG7BMKtMSQZd42LPAhW6h2w=
=8wSP
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20060209/40f1818f/attachment-0002.bin>