On Jun 27, 2007, at 1:42 AM, Sergei Golovan wrote:
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)).
Forcing the cache to be on-disk won't work well for mobile or
embedded clients, however. And what about the flash-based web
clients people have done? Those usually just read the roster from
the server, and all other data is transient. Are they required now
to keep these caches on the webserver's storage space, or are they
exempt and allowed to start with an empty cache every time you reload
the Flash application?
If so, doesn't that open the route to other entity-probing attacks,
such as someone changing their client/version information over and
over very quickly to try and force the on-disk cache to fill up? To
me, that seems a potential flaw; cache contamination goes away, but
an attack to try and fill up disk could cause more trouble, as an
example. There are solutions, but the problems should be examined
and addressed.
Similarly with the MD5 thing, it doesn't allow well for clients that
support plugins adding new capabilities; you now have to change the
MD5 for the entire client when you add new namespaces to the disco.
Under the current entity caps, you just add a new token to 'ext.'
Sure, the MD5 thing could be changed to support separate plugin MD5s
as well; that's fine, but it needs to be specced out.
These are points which could be hashed out and addressed if someone
interested in the protocols were to write up a reference
implementation and a prototype version of a XEP.
Your proposal addresses neither of those.
If the cache is long-term than it does.
Not simply; disk storage isn't a magic bullet for the problem. See
above.
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).
Some clients try this. It does, as you say, lead to lags in user
interface.
Though there are ways around that. In Astra, I actually probe folks
who don't have caps only when you either open a message window to
them, or mouse-over the contact; by the time you click to get the
context menu, or actually hit enter to send a message, I've usually
been able to probe the capabilities in the background. It's not
perfect, but it works when I cannot get caps data.
I notice you still don't address point two of my suggestions, which
was 'write up your idea as a XEP.'
You have an idea for an on-disk permanent capabilities cache per-jid,
as an alternative to caps. You should write a XEP. Jacek can write
a XEP for the MD5-caps idea. They can both be put forward, the
reference implementations compared, and people can decide which one
to go with.
Not having a XEP means nothing happens. It's the issue we have right
now with file transfers; we have a XEP specifying stream-initiation
which works for file transfer, but we do NOT have any XEP specifying
the Jingle-based file transfer that Google Talk uses. Thus, no one
can even assess (much less interoperate with) the Google Talk method;
we're stymied on that, and so everyone stays with stream-initiation
for now.
If you want a new protocol, write a XEP and a reference
implementation. I'm not, really, arguing the points of either
suggested implementation... just that it's less productive to wave
around one-paragraph definitions of ideas, instead of turning them
into useful XEPs.
Anyway, I'm going to sleep. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
