On 10 October 2013 16:52, Dave Cridland <[email protected]> wrote:
>
> On 10 Oct 2013 11:23, "Spencer MacDonald"
> <[email protected]> wrote:
>>
>> The Purge API is something that I have been looking for, but the spec
>> doesn't appear to have any way of finding out what messages have been purged
>> from the archive, which means the local cache cannot be synced up with
>> archive without fetching it all.
>
> Astonishingly close to 5 years ago, I suggested that if we wanted to really
> have a generic archival sync protocol, we'd be best off just using IMAP.
> This is why.
>
> So removing random messages and then being able to later figure out which
> have been removed without storing buckets of state on the server is a hard
> problem. IMAP solves this by using eternally-unique ids that are numeric
> (and so collapse into ranges nicely, and are issued predictably), and
> deploying some fearsome logic, and allowing certain deletions to be
> re-transmitted.

Reminds me of: https://github.com/pushcx/sup/blob/master/lib/sup/imap.rb#L12
(warning: strong language ahead!)

> But it's hard - I think there's a good argument for moving any purging and
> resync to a different spec at least, and keeping MAM simple in scope.

Naturally I'd be in favour of that! Since Valérian proposed this
change I've mostly been thinking about the server-side, for which
implementing this operation is easy (and already done now by Kim in
Prosody I think). But it does change the fundamental principles of how
a MAM archive is expected to behave. Also, expanding Spencer's point,
other clients connected to the account would also need to be notified
of the deletion - and they might be offline at the time.

Potential issues if clients aren't aware of deletions is most visible
if the tail of the archive is removed, clients won't be able to fetch
from the last message they saw. In fact requesting an id that doesn't
exist should probably fetch the whole archive (with the old message
has gone, and the whole remainder of the archive is new to the
client).

Regards,
Matthew

Reply via email to