[OpenSIPS-Users] SIP Presence Aggregation Issue

[Iñaki Baz Castillo]

2010/4/1 Adrian Georgescu <ag at ag-projects.com>:
>
> 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
<ibc at aliax.net>