On 11/28/08, Steven Mak <[EMAIL PROTECTED]> wrote: > In my experience, the QUOTA function is kind of tricky.
QUOTA is nasty but thankfully it's an extension RFC I'm most interested in personal and corporate solutions where the margin cost of disk space is orders of magnitude less than the benefit. So - for example - I'm keen on solutions - such as garbage collection for unreferenced documents - which give the adminstrator much control over entropy. There have also been talk of aggressively trading storage space for performance by using exploding MIME models to avoid excessive reparsing. So I'm glad that there are people who are interested in areas like QUOTA. > There are at least > two challenges: > > 1) Return the answer quickly, that depends on the data structure that stores > the mail +1 For IMAP, the raw octet mail count probably needs to be stored as meta-data on the way > 2) Overflow, I have encountered a bug with another IMAP server where it > turned into negative number when the user got more than 4GB of mails. It's > later found that it was the datatype storing such number is not large enough > to cater the value. +1 One of the interesting aspects about mail is the range of document sizes Fancy volunteering to help add QUOTAs? - Robert > > --- On Fri, 11/28/08, Robert Burrell Donkin <[EMAIL PROTECTED]> > wrote: > From: Robert Burrell Donkin <[EMAIL PROTECTED]> > Subject: Re: JCR and IMAP > To: "James Developers List" <[email protected]> > Date: Friday, November 28, 2008, 6:27 AM > > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
