Robert Burrell Donkin ha scritto:
On Jan 22, 2008 6:39 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
it's a milestone rather than an alpha. we don't have alpha quality
code that we intend to fix up and release but a mixed bag which we
cannot promise will be compatible with an eventual 3.0 release
I agree. And if we don't plan to include IMAP then probably "2.5" would
be a better name, for what will not be compatible with 3.0, but can lead
to an intermediate release.
(it's not just IMAP but also the backend that IMAP depends on that isn't ready)
I agree, but IIRC 99% of that code is not used by the "legacy" JAMES
Server. The backend for IMAP has been written for IMAP. POP3, SMTP,
NNTP, RemoteManager still depends on the same old components. We simply
refactored a lot of service interfaces (API) used between this components.
IMHO stability of the API between components is a lesser priority
compared to the config.xml+storage compatibility for an early release.
The former is something targeting developers, the latter is something
targeting every user.
next-minor (2.4 ?): this is Noel field. My opinion is unchanged. IMHO we
should work on trunk because backporting to the old structure IMHO is
too much work and does not make sense. BTW if anyone is willing to work
on this, well, why not: the more we release the better.
depends on the feature: i was wondering about backporting components
rather than source. i suspect that this should be much easier.
I'm not sure I understand the "backporting components".
v2.3 branch is not "modularized" like trunk and there are many changes
at the api level between v2.3 and trunk, because we tried to fix up some
service interface to better modularize the components.
(moving code around into modules really isn't a substantive issue and
is easy to reverse)
I will rephrase it as: I don't get why backporting to a v2.3 branch
should be easier than choosing a bunch of modules from trunk.
Or, alternatively, I can ask a question: What, in current trunk modules
(exluding *imap* and *mailbox*) should not be backported?
(whether it's called 2.5 or 3.0) the APIs are the main issue - we
really need to take a good look at the way that JAMES is composed
I think a release with the features that are waiting since an year is
MUCH more important than discussing JAMES composition. Integers for
version numbers are infinite, so a good plan would be to release
something (as we have something to release) and then improve things in
the following release. BTW I had no success with such a plan when I was
proposing to put my forces in working on it, I don't expect to see this
happen now that I'm no more active on this (but hope is the last to die
:-) ).
I think a better plan is to try to release at least one milestone from
trunk and depending on the feedback we'll have on the milestones we'll
be able to decide whether it's better to make more milestones from trunk
or it is better to branch for consolidation.
I don't speak about IMAP (I think Robert will tell us what he thinks
about IMAP modules and their status)
IMAP is better but isn't ready
What about a release including IMAP only as an experimental/alpha
module, but having the remaining server as a 2.3 backward compatible
server with some improvements?
the current backend APIs touched by IMAP are not satisfactory:
releasing them will just create yet another fork without IMAP. we'll
end up in exactly the same situation
until someone steps up to sort out the APIs, milestones are the best approach
I agreed and agree that milestone is the best way.
Once users will test the milestone we'll collect experiences and we'll
be able to decide how to proceed.
but I think most of the other
modules in trunk are ready (since 13 months) for a milestone/alpha/beta
release and they already provide a lot of new features compared to
2.3.1. Most of the code in trunk should be storage and config.xml
compatible with 2.3.1.
i'm not sure how true is (there are a number of features touched by
IMAP which aren't ready)
What features? The mailboxmanager is only used by IMAP. I don't think
there is much core code that has been changed to accomodate IMAP
modules. Had I forgotten anything?
mailbox manager and implementations are the major areas. this couples
over to some some other functions such as jsieve integration.
Again we have in trunk 3 things:
A remodularized and slightly improved v2.3 codebase + spring deployment
+ a lot of new code for IMAP and its backed. They are 3 totally separate
and different things.
it's the APIs that are important: IMO the API dependencies really need
to be understood and sorted out
Most users don't care about APIs but instead they care of features. Of
course it is good to be able to target also developers and to have
better API. IMHO a better API is not a good cause to delay a release for
1 year. Yes, most new features are there since more than 1 year and IMHO
there is no good explanation for this when we reply to some server-user
questions.
- SMTP Server
- 8bitmime support [beta]
- Greylisting support [alpha/norman?]
- SPF support [beta]
- Better SpamAssassin support [beta]
- Support for POP-before-SMTP (roaming users) [norman?]
- URI blacklist support [norman?]
- URIRBLHandler for fastfail [norman?]
- Add reverse lookup checks and HELO/EHLO checks in SMTP [norman?]
- Support Connection Limit per IP [beta]
which of these improvements are in the protocol and which are mailets?
Everything in protocol.
- Virtual hosting / Dynamic reloading / JMX+RemoteManager management
- introduced the VirtualUserTable (VUT) Service [beta]
- Support dynamic reload of servernames [beta]
- Added JMX+RM operations for spool/mail repositories and user
management. [bernd?]
- Support the use of VUT to extract servernames. [beta]
- Added management for the new VUT store/repository. [alpha/beta]
- Added management interfaces and remotemanager commands to manage the
servername list [alpha/beta]
how is virtual hosting coupled to the protocols?
Most of virtual hosting support has been achieved by altering service
interfaces and contracts between components. Protocols interact with the
service interfaces. Many core interfaces/components have been changed
(sometimes slightly) to add this features, but I think this resulted in
a better separation of concerns between core services.
Well, this seems a plan. What is blocking mailet/jsieve/mime4j releases?
mailet, jsieve - energy
About mailet: do we want to delay the next major release of JAMES Server
until we'll have defined the next generation mailet API or do we want to
cut a earlier JAMES Server release against the latest released mailet API?
jSieve: do we just need to package a release, review and vote on it (I
don't see open JIRA issues for 0.2)? I think we already discussed the
possibility to release it on 24/10/2007 and everyone agreed we were
ready. I can't sign releases, but I can support with any other related
task (review, run tests, update JIRA and website for the release, add
the news, etc).
mime4j - completion of refactoring
I'm not sure how much energy this will take and how we should delay a
release, but why don't we release 0.4 based on the current codebase and
then refactor more in 0.5 ?
We did this with jSPF and we made a lot of releases. I think it is
better to have many incompatible releases than no releases ;-)
Having a release means that users will download and test it, and will
report bugs against a specific codebase.
I think we solved most of legal issues related to the release of mime4j.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
