On 6/27/07, Rachel Blackman <[EMAIL PROTECTED]> wrote:
>> But that violates the /entire purpose/ of the XEP, and basically
>> makes it useless.
>
> It would make it useless if everyone used a new client on every new
> connection. While someone uses the same client version there's no need
> to constantly disco it. So, the aim of the XEP is achieved (for the
> higher cost however).
But the high cost is primarily -- indeed, I would say almost /
exclusively/ -- when someone logs on and probes their entire roster.
Or when someone logs in for the first time in a day or so, and all
their contacts probe them; usually the cache will be gone for at
least some of the contacts by then, as many people restart their
clients (and thus lose the cache) every few days due to a Windows
reboot or wanting to play a game and not be bothered, or whatever.
When I think about caching I think about long-term caching (on-disk,
not in-memory, memory caches are even more dangerous for me as someone
may simply send me new presence every few seconds and eventually
overfull the memory (or there should be some sort of cache expiration,
which leads to extra network load)).
Your proposal addresses neither of those.
If the cache is long-term than it does.
>> The situation we used to have was that someone would come online, and
>> other people would disco probe them. Every single resource that came
>> online. It generated too much traffic, both as you came online and
>> all your contacts probed you, AND as you had to probe all your
>> contacts. It was bad. It needed a solution; the solution is, thus
>> far, this XEP.
>
> But the security flaws are inacceptable for me in this solution.
I'm not arguing that the perceived flaws may be unacceptable to you
personally here, but you already have two viable options for
addressing that.
First option, in your implementation you can just individually probe
each of your contacts (or, even, just disco and cache based on jid
and client/version, as you suggested) and suffer the potential
network-karma penalty if a user logs in and has 200 contacts online
to probe. Just keep in mind that many people still consider putting
avatar hash data into presence to be too much potential network spam,
so you may face some opposition from mobile client users who pay for
their bandwidth by the megabyte. (I.e., the same argument about high
cost that led to entity caps in the first place.)
The contacts could be probed by disco requests on demand, and not on
every login (though this approach will lead to undesirable lags in
user interface).
But if the information is stored on disk then there's no need to query
contacts on login (except the firat one).
However, in this case, caps already has /many/ implementations, as a
great number of clients use it successfully. And I'm pretty sure it /
is/ one of the few that actually had a reference implementation
provided way back when. :)
I'd say that it's not easy to define 'successfully' in this case. Can
users easily notice that a remote client offers incorrect
capabilities? And what's the difference for the user if remote client
doesn't support XEP-0115 at all? Do users feel some inconveniences in
that case?
--
Sergei Golovan
