Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and… (new subject)

[Iñaki Baz Castillo <[e-mail]>]

2012/11/2 Saúl Ibarra Corretgé <[e-mail]>:

>> buddylist:
>> --------------------
>> sip:[e-mail] {
>>  presence-subscribe-to: true,
>>  presence-allowed: true,
>>  presence-blocked: false
>> }
>>
>> sip:[e-mail] {
>>  presence-subscribed-to: true,
>>  presence-allowed: true,
>>  presence-blocked: true
>> }
>> --------------------
>>
>> And that's all. This is easy to render for the watcher and easy to
>> process for the server. Single "document" with buddies and their
>> attributes.
>>
>> No need for "external references to other XCAP documents in any other
>> server in the world", no need for generating a coredump if the same
>> buddy is contained in "oma_my_buddies" list and "my_blocked_contacts"
>> list and "oma_PoC_contacts" list and "oma_featured_buddies" list.
>>
>
> This is what we did in our addressbook implementation, while maintaining compatibility to the highest possible degree.

And what is the point in "mantaining compatibility" if no other SIMPLE
client will understand the advanced document format of your
resource-list document? (they will probably delete it and regenerate
it).

And, if we just need a single document (based on buddies with
attributes) why do we need so many scattered XML/XCAP documents in the
server? and why does the presence server need to deal with N XML
documents and external references between them?

Why do we need a "RLS document" for presence subscription if we can
set an attribute "presence-subscribe-to" for each buddy in our
buddylist so the server already knows which users to subscribe to? Why
do we need a pres-rules documents if authorization rules are given via
buddy attributes? why do we need 95% of SIMPLE/XCAP specs if a single
document is enough?

And why to mantain "backward compatibility" if there is NO one full
working SIMPLE client out of walled gardens (apart from Blink which,
finally, works well but just when using the server infrastructure
designed for it)?




--
Iñaki Baz Castillo
<[e-mail]>