@Eric: I think Jochen should just code in the imap trunk for now.. We will merge it later then. As the code in protocols need many more work :/
Bye, Norman -- Norman Maurer Am Freitag, 6. Januar 2012 um 18:34 schrieb Eric Charles: > As a side note, we are moving IMAP code from > > https://svn.apache.org/repos/asf/james/imap/trunk/ > to > https://svn.apache.org/repos/asf/james/protocols/trunk/imap/ > > I would be better that you code in the latter. > > Thx, > Eric > > > On 06/01/12 12:25, Jochen Gazda wrote: > > Gentlemen, > > > > Please read and comment. > > > > I have started to implement the ACL support. In the very first phase I > > would like to > > - add support for IMAP GETACL command and > > - add support for storing ACL at least for one storage backend. > > > > During this first phase I would like to learn how to do things in a > > James-compiliant way so that I will be able to implement other ACL > > commands later. > > > > 1. A new interface org.apache.james.mailbox.MailboxACL and default > > implementation org.apache.james.mailbox.store.SimpleMailboxACL > > Stores an ACL applicable to a mailbox. Inspired by RFC4314 IMAP4 > > Access Control List (ACL) Extension. > > Note: An ACL class that could serve our purpose exists in > > com.sun.mail.imap. We will not stick to a proprietary API, will we? > > > > 2. MailboxACL usage: > > org.apache.james.mailbox.store.mail.model.Mailbox<Id> and > > implementations will be extended to store the related ACL: > > MailboxACL getACL(); > > void setACL(MailboxACL acl); > > This is probably OK. > > > > 3. MailboxACL usage: org.apache.james.mailbox.MessageManager.MetaData > > will be extended to offer a read access to the ACL of the related > > mailbox. This was approved by Norman Maurer. > > MailboxACL getACL(); > > > > 4. MailboxACL usage: Under org.apache.james.imap ACL-related requests, > > decoders, responses, encoders and processors will use MailboxACL. > > It is probably OK as there is a lot of org.apache.james.mailbox.* > > usage under org.apache.james.imap. > > > > 5. MailboxACL instantiation: Clearly, there will be (at least) two > > places where MailboxACL will be instantiated: > > i. In Mailbox implementations when reading ACLs from their backends > > ii. In org.apache.james.imap decoders when parsing the ACL related > > IMAP requests. > > > > At the moment I have hardcoded a constructor of my default > > implementation on both places. I am asking myself if some kind of > > factory pattern should be used instead. > > > > 6. How to access an ACL stored in a mailbox backend from a subclass of > > org.apache.james.imap.processor.AbstractMailboxProcessor: > > At the moment I have this code to prepare a response for GETACL IMAP > > command: > > MessageManager messageManager = > > getMailboxManager().getMailbox(buildFullPath(session, mailboxName), > > mailboxSession); > > MetaData metaData = messageManager.getMetaData(false, > > mailboxSession, FetchGroup.NO_COUNT); > > > > I have not tested it yet, but principally, it should work. I only > > wonder at two things with that code: > > > > i. org.apache.james.mailbox.MailboxManager.getMailbox(MailboxPath, > > MailboxSession) > > It returns a MessageManager rather than a Mailbox. Should it not > > rather be called getMessageManager? > > > > ii. org.apache.james.mailbox.MessageManager.getMetaData(boolean, > > MailboxSession, FetchGroup) > > Javadoc says "Gets current meta data for the mailbox." Why is > > this method in MessageManager and not in MailboxManager? > > > > 7. What and in which order should the GetACLProcessor say after > > sending the ACL response? > > i. Should it send also unsolicitedResponses? > > ii. unsolicitedResponses should be sent before or after okComplete? > > iii. on MailboxException, we send no() and I wonder what should its > > HumanReadableText say? > > iv. is the no() sufficient for all exceptions? What if somebody is > > asking for ACL of a folder which > > (a) does not exist or > > (b) cannot be looked up by the current user? > > Isn't taggedBad more suitable for (a) and/or (b)? > > > > Here is what I have now: > > > > @Override > > protected void doProcess(GetACLRequest message, ImapSession > > session, String tag, ImapCommand command, Responder responder) { > > final MailboxManager mailboxManager = getMailboxManager(); > > final MailboxSession mailboxSession = > > ImapSessionUtils.getMailboxSession(session); > > try { > > String mailboxName = message.getMailboxName(); > > MessageManager messageManager = > > mailboxManager.getMailbox(buildFullPath(session, mailboxName), > > mailboxSession); > > MetaData metaData = messageManager.getMetaData(false, > > mailboxSession, FetchGroup.NO_COUNT); > > ACLResponse aclResponse = new ACLResponse(mailboxName, > > metaData.getACL()); > > responder.respond(aclResponse); > > okComplete(command, tag, responder); > > //FIXME should we send unsolicited responses here? > > //unsolicitedResponses(session, responder, false); > > } catch (MailboxException e) { > > // FIXME: be more specific in the human readable text. > > no(command, tag, responder, > > HumanReadableText.GENERIC_FAILURE_DURING_PROCESSING); > > } > > } > > > > > > 8. Interpretation of ACLs: > > To have ACL stored on every mailbox is far from being able to tell if > > the given user can perform the given operation for the given > > mailbox(es when copying/moving). > > A new service responsible for resolving of ACLs is necessary. I > > propose to call it MailboxACLResolver. > > In which package should it be placed? Also in org.apache.james.mailbox? > > Probably every single operation between IMAP and mailbox stores should > > pass through this service. Where in the code should such a permission > > enforcement be placed? > > How should MailboxACLResolver be instantiated? > > > > 9. A new event type: > > org.apache.james.mailbox.MailboxListener.MailboxACLUpdated > > It is quite clear what it should look like. It is also quite clear to > > me where and how it should be fired. > > But I cannot figure out who should listen to it and what the listener > > should do. > > > > > > Thanks, > > > > Gazda > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > > (mailto:server-dev-unsubscr...@james.apache.org) > > For additional commands, e-mail: server-dev-h...@james.apache.org > > (mailto:server-dev-h...@james.apache.org) > > > > > -- > eric | http://about.echarles.net | @echarles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > (mailto:server-dev-unsubscr...@james.apache.org) > For additional commands, e-mail: server-dev-h...@james.apache.org > (mailto:server-dev-h...@james.apache.org) > >
