2010/4/1 Adrian Georgescu <[email protected]>: > > On Apr 1, 2010, at 3:10 PM, Schumann Sebastian wrote: > >> Hi Bogdan >> >> Yes, in an "ideal world", this re-publishing with BUSY and ONLINE is >> wanted, but the toggling not. Priorities would help (you'd receive >> that but not trigger anything on the user interface as the highest >> priority will keep its state), but we don't have them yet, so in >> that case the decision must be made somewhere else or not at all. >> > > All we need is a good client to figure out how to use these concepts, > right?
And as those concepts are not standarized we would end with a custom/propietary implementation, perhaps 100% based on the *vague* RFC's about SIMPLE, but just interoperable with itself. I have another idea: just drop SIMPLE/XCAP, the worst "protocols" in the world. After spending more than 6 months fully immersed in SIMPLE/XCAP specifications I strongly recommend to everybody not to waste your time with this abominable experience. Even if you get all the specifications to work, you would end with a limited presence system: - An inneficiente presence server because it must re-calculate all the user permissions each time the user modifies its resource-lists or pres-rules document (there is no concept of "adding a budy" here). - A "cool" buddy list in which for each buddy you just can set its uri and its display-name (no groups, no other PIM data, no static photo, nothing). - An unfeaseible way to determine how many "resources" exist for a buddy as all its presentities are mixed/grouped with no real criterion. - A hypercomplex mechanism to publish a photo, mixing different protocols. - And better if we don't speak about RLS and so... -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
