Waqas Hussain píše v Pá 05. 02. 2010 v 22:39 +0500:

> 
> 
> I have an alternative suggestion :)
> 
> 
> <x xmlns='http://jabber.org/protocol/muc#user'> 
>   <status code='210'/>
>   <status xmlns='urn:xmpp:mucstatus:0'>
>     <roomnick-rewritten/>
>     <real-jid-enforced/>
>     <custom xmlns='helo:wrld'/>
>   </status>
> </x>
> 
> 

Right, the custom status does not need to be associated with the generic
one explicitly. It's meaning is implicit. Didn't occur to me before. 

> Using <mucstatus xmlns='urn:xmpp:mucstatus:0'/> instead of <status
> xmlns='urn:xmpp:mucstatus:0'/> might make some folks happier, though
> existing implementations wont break on either.
> 

Depends on the XML implementation. Some people use custom code that
doesn't care much about namespaces :)

But we shouldn't care much about broken code either I suppose.

> 
> Advantages of this approach.. It's concise. It's cleanly separated
> from legacy status codes. The other suggestions seem like patches
> tacked on legacy status codes (they are children of the legacy status
> element, which is an unnecessary dependency IMHO).
> 

+1

> 
> Argument against keeping the <status/> element.. The <status/> element
> can appear multiple times.
> 
> 
> <status xmlns='urn:xmpp:mucstatus:0'>
>   <roomnick-rewritten/>
>   <real-jid-enforced/>
> </status>
> 
> 
> seems cleaner to me than
> 
> 
> <status>
>   <roomnick-rewritten xmlns='urn:xmpp:mucstatus:0'/>
> </status>
> </status>
>   <real-jid-enforced xmlns='urn:xmpp:mucstatus:0'/>
> </status>
> 

Yeah. It is cleaner. But there is one other thing I was thinking about.

Most of the "status codes" actually don't have anything to do with any
"status". They are either a notification of settings change, or a marker
for a special stanza, or a combination of both. Does the name "status"
make any sense?

As for the settings notifications, I think there should really be a more
generic mechanism for those.

> 
> What exactly is the advantage of keeping the old <status/> element? I
> don't see it making implementation or documentation easier.
> 
> 

So as not to need to dig too much in the spec I suppose.
However, if the status codes are not needed, I don't see a reason for
not deprecating them right away.

> --
> Waqas Hussain
> 
> 


Attachment: signature.asc
Description: Toto je digitálně podepsaná část zprávy

Reply via email to