On 07/26/2012 07:28 AM, Bron Gondwana wrote: > https://bugzilla.cyrusimap.org/show_bug.cgi?id=3723 Thanks. >> If these bugs are confirmed, it'd be great to have them fixed before >> this extension is widely adopted (there are lots of potential, imo), >> otherwise client implementations might be based on the current Cyrus >> version which is the de facto normative implementation, and the examples >> from the RFC would overrule the ABNF. > > Agree, have made P1. Implementing unsolicited METADATA responses at the same time would be awesome, though. Actually, I came across a discussion on the "tb-planning" list about syncing Thunderbird and Gaïa <http://goo.gl/Q0tG1>. Someone says that there's no sync capability with IMAP, but that's not true. IMAP METADATA can be used as a remote storage mechanism, in the ACAP spirit, although some old-school IMAPers might strongly disagree. Stored data would be related to client configuration mainly, the address-book could be stored there as well, but pointing to an URI (LDAP, CalDAV) might be better. But I see several problems : - lack of selective notifications : a client might not be interested into receiving some classes of METADATA events, and I don't think the NOTIFY extension would solve the problem there ; - lack of diff-like mechanism at reconnection : a client might be interested into fetching metadata it doesn't know about (new, modified and deleted ones) ; - potential difficulty, although not insurmountable, to create standard interoperable schemes. All that to say that I believe the IMAP METADATA extension has a real and useful potential. Perhaps a collaboration between Cyrus, Fastmail, Mozilla (Tb & B2G) and other vendors and providers might favor its use. -- kael ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
