On Wed, Nov 26, 2008 at 10:36 PM, Patrick Ruhkopf <[EMAIL PROTECTED]> wrote: > On Wed, Nov 26, 2008 at 3:40 AM, Robert Burrell Donkin > <[EMAIL PROTECTED]> wrote: >> It took me about a year to learn enough about IMAP to create a working >> implementation but the good news is that the hard leg work's over now >> - a comprehensive functional test suite exists together with working >> IMAP commands and codecs. > > Sweet! I've heard that imap is quite complex. I guess I don't want to > know all the reasons.
+1 > If only we could "reinvent Email using REST" [1]. ;-) that particular windmill is one i've been tilting at obliquely for a couple of years now ;-) >> I'd much rather start from first principals by designing a good model. >> I'm very familiar with the actual requirements (rather than the API's >> requirements). Second, create a fully working and tested module just >> containing the JCR stuff. Third, create an adapter module (probably by >> cloning the torque module) between the API and the JCR module. > > Sounds like plan. We just have to keep an eye on 3) along the way so > that writing an adapter doesn't become a complex time consuming task > spoiling the work done in 1) and 2). i'm now very familiar with IMAP's actual requirements and the inadequacies of the current API so 3) shouldn't be too much of a problem let me by start by giving a whirlwind tour of essential IMAP. please dive in an ask questions, comments and ideas... IMAP has three primary concepts: user, mail, mailbox. as well as authentication and authorisation, users have subscriptions (links to mailboxes). each mail is a MIME-typed read only document with meta-data a mailbox is a container for mail. additional mutable per-mailbox meta-data is set for each mail. probably more elegant to use links than actual containment. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
