On Sat, Feb 13, 2010 at 10:43 AM, Peter Saint-Andre <[email protected]>wrote:
> On 2/5/10 10:39 AM, Waqas Hussain wrote: > > > What exactly is the advantage of keeping the old <status/> element? > > Backward compatibility. What exactly does that mean? Does it lead to reduced code complexity on the server or on the client? > Is your proposal that services would send both > the old <status/> element(s) and your proposed <mucstatus/> element > (with potentially multiple children)? I don't see many benefits to that. > > The main reason I'm opposed to the old <status/> element is that the <status/> element can occur multiple times. Iterating over the children of all <status/> elements leads to awkward edge cases. This is increased code complexity on the client. Consider: <status xmlns='jabber:client'><ns1:child1/><ns2:child2/></status> <status xmlns='jabber:client'><ns3:child3/></status> How should a client interpret the above? Does it take one child from each <status/> element? Which one? Does it merge them? And note that these children are in a different (possibly unknown) namespace; forbidding multiple such children in the schema would be even more awkward (not to mention against the spirit of namespaces). And then there's the aesthetic reason. The following <status> <child1/> <child2/> </status> seems more readable to me than <status> <child1/> </status> <status> <child2/> </status> In the end, despite writing all of the above, I'm not actually too strongly opposed to doing it either way. -- Waqas Hussain
