[Standards] Re: [jdev] XEP-0115: Entity Capabilities
rcb at ceruleanstudios.com
Wed Jun 27 03:58:52 CDT 2007
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
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
>> 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
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
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 <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/
More information about the Standards