[Standards] XEP-0136: last call feedback

Peter Saint-Andre stpeter at stpeter.im
Fri Apr 11 17:36:02 UTC 2008


Alexander Tsvyashchenko wrote:
> 
> Hi Pieter,
> 
> Some comments on some of your comments ;-)
> 
> Quoting Peter Saint-Andre <stpeter at stpeter.im>:
> 
>> 1. Replication
>>
>> The text in Section 9.4 says:
>>
>> "Along with its copy of the archive the client SHOULD save the most
>> recent <last/> identifier that it received from the server. The next
>> time it synchronizes with the server it SHOULD specify that identifier
>> when requesting the first result set page (see above)."
>>
>> However, it's not clear how the client can specify the <last/> value
>> when it requests the first result set page. Would that be something like
>> this?
>>
>> Example 61. Requesting a page of modifications
>>
>> <iq type='get' id='sync1'>
>>   <modified xmlns='urn:xmpp:tmp:archive'
>>             start='1469-07-21T01:14:47Z'
>>             version='3'/>
>>     <set xmlns='http://jabber.org/protocol/rsm'>
>> ==>   <last>rh49al47fh2nzljjfh2lww</last>
>>       <max>50</max>
>>     </set>
>>   </modified>
>> </iq>
> 
> Well, I would say just use XEP-0059 <after> element, no? 

Duh, you're right. I was getting pretty sleepy last night when I wrote that.

> These would be
> regular RSM queries with standard syntax & behavior. Actually I think
> there's no need to specify anything more other that <last> ID is
> persistent, so it can be reused between sessions, but that's already in
> place.

Agreed.

>> 3. The 'with' attribute
>>
>> We still need to finalize how we're going to handle wildcards.
> 
> I thought you're almost convinced to use 'exactMatch' approach, or have
> you got any better idea?

Yes I'm almost convinced, and no I don't have a better idea. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080411/53918ef4/attachment.bin>


More information about the Standards mailing list