2010/10/21 Daniel-Constantin Mierla miconda@gmail.com:
On the other hand, this is just exchange of content, like voice call is. I can send to my peer a link to a web resource from where to download
Then blocking a user not to view your avatar is not possible. Sending the image into a SIP message (as XMPP mainly does) is better IMHO.
clients can start a machine-to-machine session for a file transfer. This actions are done upon my agreement on what to allow for the other peer, whether I decided to store the rules locally or used a remote storage engine like xcap or http server.
I have a non very powerful phone, why should you send me advanced presence information if my device cannot render it? will you send a photo to my Linksys ATA? why should I receive information I'm not capable of rendering? why should I receive information I haven't asked? As I said before, XMPP solves this problem with publish-subscribe mechanism when coming to advanded presence (not just "online - I'm at home").
Subscriptions (including filters in the subscription) can help with this. Sending direct presence doesn't allow it. XMPP confirms this.
I don't like my provider to control everything related to my person. I may have different avatars for different persons or locations.
This is not impossible with centralized logic IMHO.
But end-to-end freedom of communication must exist. Presence update is a communication to the other peer.
Only if such peer has asked you for such information, am I wrong?
Like we do with calls, e.g., permanent redirect, there can be static rules for im and presence. But requiring/imposing support of some functionality and control from core network would not be successful in long term.
Yes, but as I said before, how can a watcher get information from you when you are offline (this is, you cannot send such information from your device to the watcher)? Couldn't the watcher get your vcard or your avatar neither your offline status information? if this feature makes sense (and IMHO it does as exists in all the IM/presence protocols) how to implement it without subscription?
The server sends 30 notifies, so you save half of the communication. There is a feature called parallel forking, we can branch a request in as many destinations as we want. That doesn't imply states on server, just a list stored in db.
So then I cannot filter some information to some specific watchers (i.e: I want a specific watcher not to see my geolocation).
And worse: Not all the information a watcher wants to retrieves depends on the watched user itself. The avatar, the user profile (a vCard) is retrieved from the server (this is true in XMPP, MSN, Skype....), so "distribute presence" cannot work here. So, should we implement two mechanims for retrieving buddy's information (one for realtime presence status and other for permanent information stored in the server? I don't think this is a good design.
I will comment separately later, this is getting big.
There is a lot to discuss about it, even more than the sum of RFC's about SIMPLE XD
Regards.