I'm a bit lost on this.
I think this kind of decisions should be driven by proposals from people
that will actually do things.
Are you saying that you are willing to create a pop3 protocol library
and to push a release of james server not including imap? In this case
+1, otherwise -1 to remove imap on the basis that someone (and I heard
no one at this time) may want to release trunk without it.
I don't want to push a release, but If I did I would try to release a
milestone from trunk "as is". Releasing should not be something that
slow development.
Anything that is not in trunk will be out of sync soon and deprecated
sooner than we could expect (e.g: pgp sandbox, handlerapi branches,
mailet api refactorings).
I just read again the previous thread:
http://markmail.org/message/y4cpeb2smpetlntf
and expecially this:
http://markmail.org/message/kf2p6gwcowogs2mp
Stefano
Robert Burrell Donkin ha scritto:
i think we're quickly reaching a time where different agendas for
JAMES will start to come into conflict with one another. i believe
that many community problems just reflect problems with structure and
modularity. so again, i'm going to suggest a technical solution to
avoid a community problem.
i think that sometime soon, people are going to want to look at
releasing (in some form) what's in trunk but IMAP is still under very
active development. once all functions are tested, next on the agenda
is a complete rewrite of the backend code. for the last week, IMAP
failures due to changes in mime4j broken JAMES. JAMES didn't really
need to upgrade until a more stable release but IMAP requires some of
the new functions. this conflict of interests led to a week of broken
tests.
i've said before that i would really like to see the protocol handling
components moved out of JAMES server and into lightweight independent
libraries capable of embedded reuse elsewhere. this would open up uses
of these components in other environments. for example, by mixing
basic POP3 into a standard java application. the libraries would not
perform socket or thread management: they would be toolkits from which
mail servers could be built. they would have no coupling to avalon.
JAMES server 3.0 would be build up from these components adding in
container services and blending all together into a standard compliant
application. i think that this approach will increase the chances of a
3.0 release (of some sort) happening as well as allowing other
projects to reuse JAMES components more easily.
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
