2010/10/21 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>