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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > !EXCUBATOR:1,44a6a12548531464817909!
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
