[Standards] XEP-136 and XEP-59 implementation comments
ogoffart at kde.org
Wed Nov 14 15:15:18 UTC 2007
Le mercredi 14 novembre 2007, Alexander Tsvyashchenko a écrit :
> Hello All,
> When working on mod_archive_odbc implementation (XEP-136 support for
> ejabberd) and libwsw (the library for XEP-136 support on clients side)
> I discovered different issues with XEP-136 standard which I’d like to
> present here, in the hope that they still can be addressed until
> XEP-136 goes “gold”.
> I hope posting those issues here is the right way to start discussion
> about their resolution, if not - I appologize for that and would
> appreciate if someone points me to the right way of doing it.
> For those issues that have proposed solutions, support for these
> solutions was implemented and verified in mod_archive_odbc and libwsw,
> so they’re certainly feasible.
> The HTML version of these comments is available at
I agree with most of what you wrote.
I'd like to comment some points:
> Who changed it?
> Typically the client will perform replication when it has some local cache
> for collections / messages, to synchronize its cache with server one.
> Therefore, it makes sense that client also use this cache for caching those
> collections client uploads.
> However, implementing it strictly according to XEP-136 means that client
> has no way to determine if the changes received in replication were done
> by this client or not - so, it will have to re-fetch entire collection even
> if <changed> item in replication results was caused by upload from itself,
> thus basically downloading the same collection it just uploaded on the
> server, which is stored already in local cache.
Can't the client first synchronize his cache before uploading ?
> Proposal: extend replication answer to include "by" attribute, which
> specifies full JID of entity who made that change. Then client that
> receives replication results can verify if the change was done by itself or
> not, thus discarding those changes that are cached locally already.
> <iq type='result' to='romeo at montague.net/orchard' id='sync1' >
> <modified xmlns='http://www.xmpp.org/extensions/xep-0136.html#ns'>
> <removed by='romeo at montague.net/pda'
> with='balcony at house.capulet.com'
> This change can be done with complete backward compatibility, as it's just
> extends the answer format.
But the ressource is not a valuable identifier.
You can connect from another client or elsewhere with the same ressource name
(not in the same time of course)
> File format
> From my experience it seems that limiting one file to conversation with
> just one JID is too restrictive - dealing with one single file for all JIDs
> is much more convenient in many cases than with a bunch of files.
I think file format is implementation detail, and should NOT be part of that
XEP at all.
That section should be removed.
Maybe it can be part of a separate XEP later (there are already other im log
specification elsewhere anyway) or extention to XEP-0227, but it's not
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the Standards