On Oct 10, 2013, at 3:27 PM, Matthew Wild <mwi...@gmail.com> wrote: > Hi Valérian, > > On 10 October 2013 05:56, Valérian Saliou <valer...@valeriansaliou.name> > wrote: >> Hello everyone, >> >> I'm re-escalating my request for XEP-0313 update, which purpose is to bring >> a way to change the user's message archiving preferences (something very >> basic, so that we keep things simple and respect the philosophy of MAM which >> is to remove the burden of previous message archiving XEPs). > > Sorry about the delay in processing your contribution. I've not had > much time to work on XEP stuff the past couple of months.
No problem to that ;) > >> You can find the Web browser-viewable version of the updated specification >> there: >> https://demo.frenchtouch.pro/valerian.saliou/xmpp/extensions/xep-0313.html >> Also, my previous update request from August on this mailing list: >> http://mail.jabber.org/pipermail/standards/2013-August/027873.html > > I had some questions about it from the other day which I can't recall > right now (and I'm going out). I was going to email you at the weekend > to see how your implementation of your changes was working out. Well since we discussed about MAM this summer, nothing more has been added. Our implementation in Jappix (client) and Metronome (server) is pretty stable and works great. Changes have only been bug fixes and performance improvements (mostly on server-side) rather than feature additions. I can tell you from a Web-client point of view that MAM (in its updated version) is just okay, and should be ready for implementation in more clients. Since we're Web only with Jappix, we have no archive synchronization between a local and remote database, though we could have such a feature with localStorage or more advanced IndexedDB. Our server implementation (courtesy of Marco Cirillo aka Maranda) is also working well in production environment, with more than 300 unique users simultaneously using the module (and much more over a larger timespan). Our server module has been coded from scratch, we considered the Prosody MAM module as too performance scratching for production and large-scale environments (as it serializes the whole message stanza before storing it as an XML/Lua object in DB and then unserialize it to send it back on retrieval - where on our side we only store the body and some critical information). Also, would be nice if someone could code an ejabberd and an Openfire implementation, this would really push clients forward to implementing it quickly. > > Oh, I think one of my questions was that it might make more sense to > be able to delete by id (individual message), or even range of ids. > This is a bit awkward to implement, as it doesn't really make sense to > use RSM for deletion IMHO - but that's how access-by-id is > implemented. Thoughts? > You mean we'd better use RSM for purges also, instead of using the 'id' attribute on the <purge /> element? (as seen in: https://demo.frenchtouch.pro/valerian.saliou/xmpp/extensions/xep-0313.html#purge-single). Well my purge specification aims at extreme simplicity. But I understand we should be stricter to standards and rather use RSM, would make it more understandable for everyone. > Also in my todo queue are updates related to message hints. After > deletion and hints are in, I think we're ready to push for draft! That's great, did not think about those hints, might be useful for desktop clients syncing the archives from an already-existing local database! May I give you an access to the private Git repo hosting the XEP file? You can still retrieve the updated XEP XML source there: https://demo.frenchtouch.pro/valerian.saliou/xmpp/extensions/xep-0313.xml (it's kept up to date with my Git pushes in real-time) > > Regards, > Matthew Cheers, -- Valérian Saliou Jappix & FrenchTouch Web Agency founder. Uno IM product lead. More about me on my personal page.
smime.p7s
Description: S/MIME cryptographic signature
