On Sat, 2003-06-21 at 00:56, Dave O wrote: > This is correct. Particularly in Cyrus IMAP, ACL is a very useful > feature. If you don't want to know about them or set them, they work > transparently. When you do a . LIST "" *, every mailbox that you have > reading rights to is returned. Considering that Cyrus is growing in > popularity, it might be nice to support one of it's better features. > > I'd be willing to help code support for this. Any chance of it getting > accepted if it works and doesn't get in the way?
The namespace and acl stuff would probably both be needed. Namespace support in the imap code is just a matter of some glue to make multiple namespaces work the same way the single one works now. Although ... i dont know, maybe we need to export information about namespaces to the app too, which would require more api. Any new acl thing would probably want to be extensible and re-usable to other possible backends (if and where it is applicable), so the hardest part is just defining the api, and one that isn't too limited just to match whatever cyrus does. That might be a good place to start on. I was contemplating adding 'interfaces' to camel object, which might make this simpler, but it wouldn't be required - you would just extend camel-store with additional virtual methods/attributes as it stands now. FWIW we're also contemplating finally making camel an external library, although that adds additional maintenance overheads we haven't had to deal with so far. And yeah, any reasonable patch will definetly be considered, assuming it is of adequate quality, used existing styles and interfaces, is mt-safe, and so forth. Ximian requires copyright assignment documentation for any non-trivial change however. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
