[Standards] XEP-136 and XEP-59 implementation comments

[Olivier Goffart]

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
> http://www.ndl.kiev.ua/typo/articles/2007/11/14/xep-136-and-xep-59-implemen
>tation-comments

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.
>
> Example:
>
>      <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'
>                   start='1469-07-21T03:16:37Z'/>
> .....
>
> 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 
really related 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.jabber.org/pipermail/standards/attachments/20071114/f581aa6c/attachment.pgp