Sorry, I gave some more thought to this after I wrote that email and I think your proposal is better. But I haven't had time to post about it in more detail yet...
On 2/13/10 7:40 AM, Waqas Hussain wrote: > On Sat, Feb 13, 2010 at 10:43 AM, Peter Saint-Andre <[email protected] > <mailto:[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 > -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
