james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject Re: IMAP Roadmap
Date Sat, 01 Jul 2006 17:53:46 GMT
Hi Joachim,

nice Roadmap so far.. i have notime to write a large answer now ( Will
do this tomorrow). But i think you did a really good job with that and
all sounds logic to me..

bye
Norman

Am Samstag, den 01.07.2006, 18:20 +0200 schrieb Joachim Draeger:
> Hi!
> 
> 
> Joachim
> 
> 
>    [1]The ASF
> 
>    Goals
> 
>    The first goal is to have a stable but limited IMAP Server. It has to
>    scale well on middle-size installations. The user should be provided
>    with what he needs to work: A centralized inbox and the ability to
>    sort messages into self defined folders.
> 
>    This goal should be reached fast with just the features needed to
>    achieve it That means we should analyze clients and notice what they
>    are doing and how they react on limited features.
> 
>    Release Early, Release Often.
> 
>    The community feedback is the only chance for such a project to
>    survive.
> 
>    Apart from that it is also the right time to talk about visions.
> 
>    IMAP has a lot of new requirements which means that existing design
> of
>    James message and user storage API backends have to be extensively
>    refactored/rewritten. What ever we do now may be the base of future
>    development. Design limitations we introduce today could be hard to
>    overcome tomorrow.
> 
>    Having a structured, ordered and valued roadmap of what ever is
>    desireable/imaginable helps on making decisions.
> 
>    Being pragmatic may mean discarding some goals, but we should at
> least
>    be aware of that.
>    Roadmap
> 
>    Milestone 0 : Preparations
> 
>     1. Define goals
>     2. Define a roadmap
>     3. Start a glossary
>     4. Collect resources
>     5. Design an backend API that is in line with the features desired
> in
>        the roadmap
> 
>    The API could consist of a bunch of interfaces. They don't need to be
>    complete but should allow for future extension.
>    Milestone 1 : The Basics
> 
>      * Stable
>      * JDBC based ImapMailboxRepository
>      * Internal use of namespaces
>      * Full uid support
>      * Support for all basic operations for at least one client (Mozilla
>        Thunderbird)
> 
>    Supported commands: Partial supported:                 Not supported:
>    CAPABILITY          FETCH                              EXAMINE
>    NOOP                Not supported:                     SUBSCRIBE
>    LOGOUT              FETCH (BODY[<section>]<<partial>>) UNSUBSCRIBE
>    COPY                FETCH (BODYSTRUCTURE)              LSUB
>    LOGIN               FETCH (ENVELOPE)                   CHECK
>    SELECT              FETCH (FULL)                       CLOSE
>    CREATE                                                 EXPUNGE
>    DELETE                                                 SEARCH
>    STATUS                                                 X
>    APPEND                                                 AUTHENTICATE
>    STORE
>    Milestone 2 : Full Compliance
> 
>      * Nearly full compliance to IMAP4rev1 RFC2060
>      * SUBSCRIBE will still have no effect
>      * Support for all non-buggy IMAP4rev1 compliant clients
> 
>    Milestone 3 : Compatibility
> 
>      * Maybe/hopefully not needed
>      * Maybe (partial) IMAP4 compliance
>      * Workarounds for buggy wannabe-IMAP4rev1-compliant clients ;-)
>      * [2]Postel's Law "be conservative in what you send, be liberal in
>        what you receive"
> 
>    Milestone 4 : Shared Mailboxes
> 
>      * Full compliance to IMAP4rev1 RFC2060
>      * Subscriptions
>      * Basic ACL support, to be controlled by admin
>      * Shared Mailboxes
> 
>    Milestone 5 : Fancy Groupware
> 
>      * Quota
>      * Sieve integration
>      * User-defined ACL
>      * User-defined Flags (Keywords)
> 
>    Milestone 6 : Cluster
> 
>    IMAP is quite resource intensive. Mailboxes might reach the size of a
>    few GiB. Clients are not required to do any caching. Users might
>    search and wade through large message archives from day to day.
> 
>      * Large enterprise installations
>      * Many imap servers to many storage servers
>      * Automatic fallback to backup stores
>      * Fine-grained performance audit
> 
>    Milestone 7 : Imagine
> 
>      * IMAP mirroring
>      * NNTP-Integration
>      * Push IMAP
>      _________________________________________________________________
> 
>    Copyright � 1999-2006, The Apache Software Foundation
> 
> Verweise
> 
>    1. http://www.apache.org/
>    2. http://en.wikipedia.org/wiki/Postel's_Law
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> !EXCUBATOR:1,44a6a12548531464817909!

Mime
View raw message