Martin Kauss bishoph@open-xchange.org wrote
Hi,
the configure just checks the system dependencies to build the system. The needed libraries are not checked until the compile process, JFYI.
The questions was asked some month ago for a Debian package as well. I tried to build Open-Xchange some time ago with GNU Classpath, but specially for mail, necessary methods and functions are just missing.
So what I understand is this: (Correct me if I'm wrong) 1. Problems with servlets are solvable with free Java tools, and these are not major showstoppers 2. Base64 and Parserdelegator problems need some work 3. Main problem is that the free Javamail does not implement some methods that are needed by OX.
Is it possible for the OX developers to work with the Classpath developers to resolve these problems ? As far as I can understand there is no major bottleneck other than some missing functionality, and I'm sure that the Classpath people would love to have people collaborating with them. :)
We are just providing a collaboration framework and that is our focus. This means, if the functionality is covered by any other package than Sun's Javamail package one can build OX with this packages.
Currently - AFAIK - this is not possible.
The other question is what you mean with "extensive free Java tools" ... for some ppl. also packages offered by Sun/IBM/Bea are "free" ...
I generally refer to the Debian Free Software Guidelines for my definition of Free software :)
http://www.debian.org/social_contract#guidelines
Thanks a lot
On Jul 09, 2005 05:15 AM, Soumyadip Modak soumyadip@randomink.org wrote:
Martin Kauss bishoph@open-xchange.org wrote
Hi,
the configure just checks the system dependencies to build the system. The needed libraries are not checked until the compile process, JFYI.
The questions was asked some month ago for a Debian package as well. I tried to build Open-Xchange some time ago with GNU Classpath, but specially for mail, necessary methods and functions are just missing.
So what I understand is this: (Correct me if I'm wrong)
- Problems with servlets are solvable with free Java tools, and these
are not major showstoppers
I am not aware of any servlet issues at all, tomcat for example should provide all necessary libraries.
- Base64 and Parserdelegator problems need some work
Specially the ParserDelegator class should be part of a JDK since Java 1.2 as far as i can remember, see
http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/text/html/parser/ParserD... and http://developer.classpath.org/doc/javax/swing/text/html/parser/ParserDelega...
- Main problem is that the free Javamail does not implement some
methods that are needed by OX.
Correct.
Is it possible for the OX developers to work with the Classpath developers to resolve these problems ? As far as I can understand there is no major bottleneck other than some missing functionality, and I'm sure that the Classpath people would love to have people collaborating with them. :)
Not sure what you mean with "to work ... to resolve these problems", but in general the answer is yes.
Finally i would like to mention that Sun do a great Job for Javamail with the mail protocol support and with the supported mail servers and IMHO it will not be easy to get to the same functionality.
We are just providing a collaboration framework and that is our focus. This means, if the functionality is covered by any other package than Sun's Javamail package one can build OX with this packages.
Currently - AFAIK - this is not possible.
The other question is what you mean with "extensive free Java tools" ... for some ppl. also packages offered by Sun/IBM/Bea are "free" ...
I generally refer to the Debian Free Software Guidelines for my definition of Free software :) http://www.debian.org/social_contract#guidelines
Thanks a lot
Soumyadip Modak soumyadip.modak@gmail.com soumyadip@randomink.org http://www.randomink.org/soumyadip
Ciao,
Martin Kauss
Martin Kauss wrote:
So what I understand is this: (Correct me if I'm wrong)
- Problems with servlets are solvable with free Java tools, and these
are not major showstoppers
I am not aware of any servlet issues at all, tomcat for example should provide all necessary libraries.
GNU provides the servlet API 2.4:
cvs -d anoncvs@savannah.gnu.org:/cvsroot/classpathx co servletapi
If a package is needed I can make one.
- Main problem is that the free Javamail does not implement some
methods that are needed by OX.
Correct.
I haven't heard any issues raised on classpathx-javamail@gnu.org or submitted as bugs or patches at
http://savannah.gnu.org/projects/classpathx
GNU JavaMail provides all the API methods provided by the JavaMail API. If OX depends on com.sun APIs or on undocumented session properties, this is an issue for OX to resolve. If there is functionality you want exposing, there should be no problem, but you have to let us know.
Finally i would like to mention that Sun do a great Job for Javamail with the mail protocol support and with the supported mail servers and IMHO it will not be easy to get to the same functionality.
GNU JavaMail doesn't explicitly support servers, it implements the published standards. Sun's implementation supports 3 providers (IMAP4, POP3, SMTP). GNU JavaMail supports 6 providers (IMAP4rev1, POP3, SMTP, NNTP, mbox, Maildir) and we had SASL and STARTTLS support long before Sun. Arguably we provide considerably more functionality.
On Jul 09, 2005 09:54 AM, Chris Burdess dog@bluezoo.org wrote:
Martin Kauss wrote:
So what I understand is this: (Correct me if I'm wrong)
- Problems with servlets are solvable with free Java tools, and these
are not major showstoppers
I am not aware of any servlet issues at all, tomcat for example should provide all necessary libraries.
GNU provides the servlet API 2.4:
cvs -d anoncvs@savannah.gnu.org:/cvsroot/classpathx co servletapi
If a package is needed I can make one.
- Main problem is that the free Javamail does not implement some
methods that are needed by OX.
Correct.
I haven't heard any issues raised on classpathx-javamail@gnu.org or submitted as bugs or patches at
http://savannah.gnu.org/projects/classpathx
GNU JavaMail provides all the API methods provided by the JavaMail API. If OX depends on com.sun APIs or on undocumented session properties, this is an issue for OX to resolve. If there is functionality you want exposing, there should be no problem, but you have to let us know.
Finally i would like to mention that Sun do a great Job for Javamail with the mail protocol support and with the supported mail servers and IMHO it will not be easy to get to the same functionality.
GNU JavaMail doesn't explicitly support servers, it implements the published standards. Sun's implementation supports 3 providers (IMAP4, POP3, SMTP). GNU JavaMail supports 6 providers (IMAP4rev1, POP3, SMTP, NNTP, mbox, Maildir) and we had SASL and STARTTLS support long before Sun. Arguably we provide considerably more functionality. -- Chris Burdess
Hi,
first of all i want to state that i do not want to start a discussion like vi/emacs, linux/windows or something similar. For us, freedom of choice is importend and if the classpath project fits the needs - it is just fine.
Only one statement i want to clarify: I wrote that the Javamail API supports servers - maybe i should say that it has been tested against several servers (like mentioned in the notes, http://java.sun.com/products/javamail/NOTES13.txt).
I will discuss the issue of "undocumented" calls at the beginning of the next week with our developer team and i will check again the classpath API because - like i wrote - i tested some month ago and at this time some methods were not included. I want to be up-to-date.
Please be patient until we have investigated the details.
Best regards,
Martin Kauss
On Jul 09, 2005 01:21 PM, Martin Kauss bishoph@open-xchange.org wrote:
On Jul 09, 2005 09:54 AM, Chris Burdess dog@bluezoo.org wrote:
Martin Kauss wrote:
So what I understand is this: (Correct me if I'm wrong)
- Problems with servlets are solvable with free Java tools, and these
are not major showstoppers
I am not aware of any servlet issues at all, tomcat for example should provide all necessary libraries.
GNU provides the servlet API 2.4:
cvs -d anoncvs@savannah.gnu.org:/cvsroot/classpathx co servletapi
If a package is needed I can make one.
- Main problem is that the free Javamail does not implement some
methods that are needed by OX.
Correct.
I haven't heard any issues raised on classpathx-javamail@gnu.org or submitted as bugs or patches at
http://savannah.gnu.org/projects/classpathx
GNU JavaMail provides all the API methods provided by the JavaMail API. If OX depends on com.sun APIs or on undocumented session properties, this is an issue for OX to resolve. If there is functionality you want exposing, there should be no problem, but you have to let us know.
Finally i would like to mention that Sun do a great Job for Javamail with the mail protocol support and with the supported mail servers and IMHO it will not be easy to get to the same functionality.
GNU JavaMail doesn't explicitly support servers, it implements the published standards. Sun's implementation supports 3 providers (IMAP4, POP3, SMTP). GNU JavaMail supports 6 providers (IMAP4rev1, POP3, SMTP, NNTP, mbox, Maildir) and we had SASL and STARTTLS support long before Sun. Arguably we provide considerably more functionality. -- Chris Burdess
Hi,
first of all i want to state that i do not want to start a discussion like vi/emacs, linux/windows or something similar. For us, freedom of choice is importend and if the classpath project fits the needs - it is just fine.
Only one statement i want to clarify: I wrote that the Javamail API supports servers - maybe i should say that it has been tested against several servers (like mentioned in the notes, http://java.sun.com/products/javamail/NOTES13.txt).
I will discuss the issue of "undocumented" calls at the beginning of the next week with our developer team and i will check again the classpath API because - like i wrote - i tested some month ago and at this time some methods were not included. I want to be up-to-date.
Please be patient until we have investigated the details.
Best regards,
Martin Kauss
Hi again,
as i told you we have tested the current GNU classapth javamail version against OX.
Here are the results:
The complete part "Rights" is missing in the classpath implementation or i was not able to find it (http://www.gnu.org/software/classpathx/javamail/javadoc/alphaindex.html).
However, there is another big issue: If you take a deeper look into the implementation, related to the errors you get from your compiler, you see that the methods just do not match:
http://www.gnu.org/software/classpathx/javamail/javadoc/gnu/mail/providers/i... http://java.sun.com/products/javamail/1.3/docs/javadocs/com/sun/mail/imap/IM...
There are some other minor issues, but the ones above are really big ones.
I am not sure what was meant with this "undocumented" stuff, but maybe somebody can comment this and our results.
Best regards,
Martin Kauss
Martin Kauss bishoph@open-xchange.org wrote:
The complete part "Rights" is missing in the classpath implementation or i was not able to find it (http://www.gnu.org/software/classpathx/javamail/javadoc/alphaindex.html).
The problem is that Rights, as well as ACL and Quota, are in a com.sun package.
Quoting from the documentation:
``In general, applications should not need to use the classes in this package directly. Instead, they should use the APIs defined by javax.mail package (and subpackages).
...
WARNING: The APIs unique to this package should be considered EXPERIMENTAL. They may be changed in the future in ways that are incompatible with applications using the current APIs.''
The problem is that we have public javax.mail API's that return class instances from the internal package com.sun.mail.
Am Jul 13, 2005 08:17 PM schrieb David Walluck david@zarb.org:
Martin Kauss bishoph@open-xchange.org wrote:
The complete part "Rights" is missing in the classpath implementation or i was not able to find it (http://www.gnu.org/software/classpathx/javamail/javadoc/alphaindex.html).
The problem is that Rights, as well as ACL and Quota, are in a com.sun package.
Quoting from the documentation:
``In general, applications should not need to use the classes in this package directly. Instead, they should use the APIs defined by javax.mail package (and subpackages).
...
WARNING: The APIs unique to this package should be considered EXPERIMENTAL. They may be changed in the future in ways that are incompatible with applications using the current APIs.''
The problem is that we have public javax.mail API's that return class instances from the internal package com.sun.mail.
-- Sincerely,
David Walluck david@zarb.org
This message was sent using IMP, the Internet Messaging Program.
Hi.
OX makes use of the class IMAPFolder and there you have the method addRights(ACL acl) which lead us to setRights(Rights rights) and there we find the Rights.
The GNU classpath javamail API does not have the method addRights(ACL acl) and no setRights(Rights rights) in the IMAPFolder class, see
http://www.gnu.org/software/classpathx/javamail/javadoc/gnu/mail/providers/i...
The main issue is not to use class instances (replacements), the main issue is that the classpath API does currently not implement methods needed by OX.
However, you are right, the class is experimental, but for some reasons also the GNU classpath people have implement a clone of this class. In fact we/you have to investigate if OX can offer the same functionality by using other classes and what is the effort/benefit of such a change.
Greetings,
Martin Kauss
Martin Kauss wrote:
The problem is that Rights, as well as ACL and Quota, are in a com.sun package.
OX makes use of the class IMAPFolder and there you have the method addRights(ACL acl) which lead us to setRights(Rights rights) and there we find the Rights.
The GNU classpath javamail API does not have the method addRights(ACL acl) and no setRights(Rights rights) in the IMAPFolder class, see
http://www.gnu.org/software/classpathx/javamail/javadoc/gnu/mail/ providers/imap/IMAPFolder.html
The main issue is not to use class instances (replacements), the main issue is that the classpath API does currently not implement methods needed by OX.
You haven't asked for them at any time, so it hasn't even been on our to-do list.
However, you are right, the class is experimental,
It's not that it's experimental. It's that it's a private Sun implementation, it is not part of the API, and it will never be present in a free Java runtime.
but for some reasons also the GNU classpath people have implement a clone of this class.
It's not a clone. It's a completely different private implementation, that is still not part of the API.
As Stephen Crawley noted, the problem is that the public API is underspecified and in order to use advanced IMAP functionality you need to use private implementations.
In fact we/you have to investigate if OX can offer the same functionality by using other classes and what is the effort/benefit of such a change.
The underlying library used by the GNU providers is called inetlib. It provides a much lower-level API to IMAP and other network protocols. If you want performance, and you can live without a MIME framework, it may be of interest to you.
If you just want ACL support in the GNU IMAP provider, we can schedule it in for the next release.
Am Jul 14, 2005 08:26 PM schrieb Chris Burdess dog@bluezoo.org:
Martin Kauss wrote:
The problem is that Rights, as well as ACL and Quota, are in a com.sun package.
OX makes use of the class IMAPFolder and there you have the method addRights(ACL acl) which lead us to setRights(Rights rights) and there we find the Rights.
The GNU classpath javamail API does not have the method addRights(ACL acl) and no setRights(Rights rights) in the IMAPFolder class, see
http://www.gnu.org/software/classpathx/javamail/javadoc/gnu/mail/ providers/imap/IMAPFolder.html
The main issue is not to use class instances (replacements), the main issue is that the classpath API does currently not implement methods needed by OX.
You haven't asked for them at any time, so it hasn't even been on our to-do list.
However, you are right, the class is experimental,
It's not that it's experimental. It's that it's a private Sun implementation, it is not part of the API, and it will never be present in a free Java runtime.
but for some reasons also the GNU classpath people have implement a clone of this class.
It's not a clone. It's a completely different private implementation, that is still not part of the API.
As Stephen Crawley noted, the problem is that the public API is underspecified and in order to use advanced IMAP functionality you need to use private implementations.
In fact we/you have to investigate if OX can offer the same functionality by using other classes and what is the effort/benefit of such a change.
The underlying library used by the GNU providers is called inetlib. It provides a much lower-level API to IMAP and other network protocols. If you want performance, and you can live without a MIME framework, it may be of interest to you.
If you just want ACL support in the GNU IMAP provider, we can schedule it in for the next release. -- Chris Burdess
Hi again.
I stated this out in one of my earlier post, but i will make it even more clear:
Open-Xchange provides currently a collaboration server, several extensions and frameworks. We are focused on functionality and features for the users and customers. To get this functionality we are using several libraries - you can see the list in out INSTALL file. Now the question came up if OX can build by using only "free" software tools and libraries.
We can help to make such an implementation happen, but our focus is the solution and the features. Thats why we have not ask for methods. Now, if there is a strong demand and the GNU Classpath developers are scheduling the complete implementation of the required classes and methods for one of the next GNU Classpath javamail API releases, we should have some conversation how this can be implemented in a very easy way (like some kind of configure option) to support it (of course we must keep an eye on the effort ;-).
And to avoid any rumor, this strategy is part of our general developing concepts. We do not reinvent wheels we are using existing infrastructure wherever it fits our needs.
Greetings,
Martin Kauss
"Chris" == Chris Burdess dog@bluezoo.org 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.htm...
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
Tom Tromey wrote:
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?
It does; the relevant IMAPConnection methods are setacl, deleteacl, getacl, listrights, myrights.
It wouldn't be too much trouble to implement higher-level wrappers in IMAPFolder if working with them is conceptually easier, though. Also, as I mentioned before, JavaMail and JAF provide a whole MIME implementation that may be convenient.
On Jul 19, 2005 09:57 AM, Chris Burdess dog@bluezoo.org wrote:
Tom Tromey wrote:
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?
It does; the relevant IMAPConnection methods are setacl, deleteacl, getacl, listrights, myrights.
It wouldn't be too much trouble to implement higher-level wrappers in IMAPFolder if working with them is conceptually easier, though. Also, as I mentioned before, JavaMail and JAF provide a whole MIME implementation that may be convenient. -- Chris Burdess
Chris,
i will talk with Stefan about this over the next week (he is not available this week) - we will come back ASAP.
Greetings,
Martin Kauss
Hi all!
Martin Kauss schrieb:
On Jul 19, 2005 09:57 AM, Chris Burdess dog@bluezoo.org wrote:
Tom Tromey wrote:
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?
First of all, you shouldn't only write to one person. The mailing list should be used to allow everyone to participate this discussion.
It does; the relevant IMAPConnection methods are setacl, deleteacl, getacl, listrights, myrights.
It wouldn't be too much trouble to implement higher-level wrappers in IMAPFolder if working with them is conceptually easier, though. Also, as I mentioned before, JavaMail and JAF provide a whole MIME implementation that may be convenient. -- Chris Burdess
I think there are two possible solutions for this problem:
1. Start a Java Specification Request (JSR) that integrates ACLs into the non provider specific Java Mail API.
2. The author of Webmail has to add an abstract layer that implementations uses Sun provider specific or GNU classpath specific API for ACLs. This can be done through the GOF Design Pattern "Bridge".
Chris,
i will talk with Stefan about this over the next week (he is not available this week) - we will come back ASAP.
Greetings,
Martin Kauss
This are just my two cents that lead to a functional implementation that can base on commercial and free implementations. It must simply work for the normal groupware user.
Best regards,
Marcus Klein
Am Jul 19, 2005 10:26 AM schrieb Martin Kauss bishoph@open-xchange.org:
On Jul 19, 2005 09:57 AM, Chris Burdess dog@bluezoo.org wrote:
Tom Tromey wrote:
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?
It does; the relevant IMAPConnection methods are setacl, deleteacl, getacl, listrights, myrights.
It wouldn't be too much trouble to implement higher-level wrappers in IMAPFolder if working with them is conceptually easier, though. Also, as I mentioned before, JavaMail and JAF provide a whole MIME implementation that may be convenient. -- Chris Burdess
Chris,
i will talk with Stefan about this over the next week (he is not available this week) - we will come back ASAP.
Greetings,
Martin Kauss
Hi.
We are now using SUNs JavaMail API for some years, that also includes Rights, ACLs and Quota (even if they are marked as EXPERIMENTAL). These are requirements by many people which we can't just ignore. These are the reasons why we can't use GNU JavaMail at the moment. So, as soon as it's available at the GNU JavaMail we can put this into our configure so everyone has the "freedom of choice"! But is it really necessary as the JavaMail is now part of the "GlassFish Project"?
With best regards,
Stefan Preuss
-- OPEN-XCHANGE http://www.openexchange.com
"Stefan" == Stefan Preuss stefan.preuss@open-xchange.org writes:
Stefan> But is it really necessary as the JavaMail is now part of the Stefan> "GlassFish Project"?
My understanding is that the code in GlassFish is under the CDDL, which is not GPL compatible, and that furthermore Open Exchange is GPL.
Tom
java-devel@lists.fedoraproject.org
-
Chris Burdess -
David Walluck -
Marcus Klein -
Martin Kauss -
Soumyadip Modak -
Stefan Preuss -
Tom Tromey