>>>>> "Chris" == Chris Burdess <dog@xxxxxxxxxxx> writes: Chris> If you just want ACL support in the GNU IMAP provider, we can schedule Chris> it in for the next release. Martin> We can help to make such an implementation happen, but our Martin> focus is the solution and the features. Thats why we have not Martin> ask for methods. Now, if there is a strong demand and the GNU Martin> Classpath developers are scheduling the complete Martin> implementation of the required classes and methods for one of Martin> the next GNU Classpath javamail API releases, we should have Martin> some conversation how this can be implemented in a very easy Martin> way (like some kind of configure option) to support it (of Martin> course we must keep an eye on the effort ;-). Martin> And to avoid any rumor, this strategy is part of our general Martin> developing concepts. We do not reinvent wheels we are using Martin> existing infrastructure wherever it fits our needs. Let me make a somewhat more radical suggestion: if inetlib implements the needed ACL support, how about switching to use it exclusively? I think this has advantages on both sides. On the Classpath side it means that it is simpler to run Open Exchange on the free JVMs. On the OX side, this could mean bug fixes and feature additions on your schedule, as you wouldn't be dependent on Sun for updates. Also it means that you can avoid using things that even Sun asks that you not use: http://java.sun.com/products/javamail/1.3/docs/javadocs/overview-summary.html The JavaMail reference implementation from Sun includes protocol providers in subpackages of com.sun.mail. Note that the APIs to these protocol providers are not part of the standard JavaMail API. Portable programs will not use these APIs. Tom