On May 20, 2009, at 7:44 AM, Robert Burrell Donkin wrote:
On Wed, May 20, 2009 at 2:23 PM, Stefano Bagnara <[email protected]>
wrote:
Robert Burrell Donkin ha scritto:
On Wed, May 20, 2009 at 11:52 AM, Stefano Bagnara
<[email protected]> wrote:
Robert Burrell Donkin ha scritto:
i've been having a little think recently, in particular about user
postings on the list. i think i can see a realistic path if
there's a
consensus that this is the way we want to take james forward...
Observations:
* Felix Karaf (OSGi container) is very cool. this opens up lots
of
cool possibilities for mixing protocols and is very interesting
to me.
Interesting. I'd like to see a POC about it, before embracing
such a
technology.
it will support the stuff i'm interested in without invasive changes
to james. all that's needed are features (dependencies) and spring
(assembly) documents.
this means that sometime soon i won't be running pheonix locally.
most
other mail application developers (who post on list) also seem to be
using the spring deployment.
let me clarify that I think that moving to another container is a
good
thing. But I don't think that moving to any other container is
good. A
choice has to be made and it will be critical for the future. OSGi
seems
to be a good option but I still have to see a good configuration
service
for osgi components. I don't know OSGi enough to understand if this
is a
limit in the "specification" or something that simply has not be
done,
or something that exists but I don't know.
I'm not 100% sure I know what you mean by a configuration service for
osgi components but...
Spring has proposed formalizing much of their xml plan handling stuff
as the osgi blueprint service. It's getting a bunch of independent
review and (IMO) clarification and improvement and is very close to
the final spec draft. There's a TCK. A few people from servicemix
and geronimo are working on an apache implementation, currently hosted
at geronimo. So I'd recommend using the blueprint service as the
"standard" component wiring technique.
I'm not a blueprint expert.... however I think that the service only
wires up stuff in one bundle, while allowing component references to
osgi services and publishing components as osgi services. So, I think
that rather than having one monolithic server configuration file, you
can have each piece of the mail server configured in a separate bundle
and wire the large-scale component assemblies together using services.
One issue I have not yet found out how to solve in osgi is how to
locate the server installation on the file system so you can have
stuff like file-based storage relative to the installation. For
instance in geronimo we have a var directory in the server
installation and tell everyone to put their file based data somewhere
inside that, rather than trying to store it inside the application
itself somehow (as people seem to like to do with web apps) There may
be a built in or easy solution to this but I don't know what it is yet.
that's fine
i'm almost certainly going to move to karaf. i no longer have time for
avalon and i'm out of hope that any sort of consensus about new
containers for 3.x will be every reached.
* Stefano and Norman are very busy these days. so just directly
releasing 3.0 is looking harder and harder...
Trunk was almost ready for a alpha/beta release 2 years ago, so I
don't
see this so hard. This require the same effort as any release of
james-server: until no one will need a release and will take the
time to
build some test release we won't see a release.
building a release candidate is a complete waste of time unless
there
are people who are willing and able to test it. this is where we now
come up very short.
I agree. I would probably test and review an RC from trunk but not
any
build from v2.3.
so: you wouldn't be willing to review a 2.3.2 RC?
* The recent threads from users are telling us that we really
need to
have a 2.x roadmap for mail server users (as opposed to mail
application developers)
they don't care about 2.x or 3.x. IMO they simply would like to
have new
features that are in svn since years.
i used to think that but the upshot of the discussion with users is
that no they don't. james 2.x already has lots of features. most
just
want releases plus much better documentation. any users who really
cares about features more than stability is probably already on 3.x.
the great thing about already having the features in trunk is that
we
can decant them in bite-sized pieces ensuring they have been tested
and documentation written.
???? Why should an *user* upgrade to an hypotetical 2.4.0 that do not
include a single feature more than 2.3.1 but simply require java5 and
has some more smaller jars?
it's just a mailet API upgrade and java version bump, simple as that.
new users will probably pick it up (and stop complaining about
obsolete JREs), old users can take their time evaluating it.
Can you link the discussions that led you think that such a release
would find an userbase? I really don't remember one.
take a look a the current thread here on dev
Proposal:
* Use 2.x for mature, stable releases aimed at mail server users
retaining pheonix as the container
* Target 3.x at mail application developers focussing on OSGi
and Spring
* Move code from 3.x to 2.x by factoring out libraries with
multiple
modules to allow optional avalon and OSGi service support
Roadmap:
* Release 2.3.2 now (after deprecating mordered, crypto)
* Release standard mailets 1.0
* Release crypto mailets 1.1 targeting java 1.5
Make sense.
* Release 2.4 soon replacing source with jars released so far
(with
note about standard mailets)
* Compiled against Java 1.5
* Remove mordred
* Replace 2.x crypto source with released jar
* Replace 2.x mailet API with released jars
* Release 2.5 later replacing source with released jars
* Add jSPF support
* Replace standard mailet source with released jar
* Replace whichever other services have been released by then
My main concern is that this does not give features to the users.
Users
are asking for a roadmap because they want easy virtualhosting,
fastfail
and other features that are in trunk since *3 years* (yes, some
stuff
was there when we released 2.3.0 and didn't land v2.3), are trunk
specific, and backporting them is a PITA. I don't think that the
roadmap
above does worth the required work, but if anyone think so and is
willing to work on that then it will not be a bad thing.
the advantage of the above is that it's a road map and it's easy
Come on, this is not the main goal of a roadmap. Not following that
is
easier and gives our users the same benefits.
a road map just shows a way forward
but it won't fly without support and we need a road map before 2.3.2
can be released
Why do we need a roadmap for a bugfix release? v2.3.2 can be released
anytime from v2.3 branch, as is. No roadmap needed, just a release
manager.
it's the first question we're going to get so we need an answer
we need to give developers and user hope that james isn't dead
The only real features for end users in that roadmap is jSPF and
this
could be released as a mailet anyway. jSPF as it is in trunk
cannot be
done in v2.3 because of different fastfail stuff (IIRC).
fine - so let's factor out an SMTP library as well (multi-module
with
avalon and OSGi service bindings)
this means a DNS service library as well but IMHO that's a good
thing.
UserRepository is a little too much to chew ATM but i think we
should
be able to bridge the interfaces.
AIUI this'd give us improved fail fast as well
This is trunk, isn't it?
If you take v2.3 and replace smtp, userrepositories, dnsservice and
every dependency that need changes because of this (most components
depend on dnsservice) then you have trunk (just with less modules:
take
a revision from 1 year ago and you'll have v2.3 with that stuff and
no
modules ;-) ).
not really
it doesn't include IMAP or any of the other code that would need to be
reviewed and tested to release 3.0, just the new features which users
seem to want. factoring them into libraries means that any heated
debates about design can happen in isolated not as part of a bigger
quality argument about 3.x verses 2.x.
(maybe you're starting to understand the plan now ;-)
I will not work and I will not use such a branch: I don't need any
feature from that so why should I upgrade and risk bugs?
i'm running out of time to devote to james (as a project). karaf
gives
me the way out i've been looking for.
That's a real pity. If Karaf is a way out then we'll have to pay more
attention to understand exactly what we are embracing or it will be
the
next iron ball at the leg of any future release manager.
that's not needed. karaf does the stuff that i need it to do for my
interests but the spring deployment should still work independently.
hopefully s/spring/blueprint
you and norman are busy, as are most of the other developers. james
server is really close to actually dying.
Sure, but why defining a roadmap that give us useless releases should
change things?
james - as a project - needs to be able to start agreeing on road
maps. if not, then the project will die.
no road map is going to work without your support. this is the best
plan i could think of. if you can see a better alternative way
forward
then please propose it.
I don't have time, but if I'll ever have time it won't go into
v2.3. I
repeated this in the last 2 years and I didn't change my idea about
this. v2.3 works fine, is really stable, but architecturally at its
end
of life. In my view working on that source code is a waste of time.
If I'll see activity I'll try to convince people to put their
effort in
trunk and I'll try to help as much as possible that people (as I
tried
with you).
If you have limited time to spend on james I would prefer you to
simply
make imap better as a standalone library. As a PMC member I think
this
is much more strategic for the community than a feature-less
release of
a v2.4.
IMAP now works and has been tested by martin on the major mail clients
but support for avalon and pheonix will become increasingly limited
(or quite possibly non-existent)
the problem james - as a project - has with releasing is not cutting
releases (any more) but with ensuring that they are tested and
agreeing on road maps. unless something changes soon, as soon as i
start focusing elsewhere, james is going to die.
IMHO the above roadmap is mainly a developer exercise to replace
source
code with libraries and to upgrade v2.3 to java5.
it's been 3 years since the last release. it's not ambitious but at
least it's a start.
I can only repeat myself. If you like to refactor v2.3 into v2.4 by
upgrading to java5 and to more fine grained libraries just do it, but
don't ask me to help or to agree that this will make our users
happier ;-)
without your help in review releases, no road map is feasible
it's not good releasing 2.3.2 without some sort of road map
dot releases are bug fix releases. I never ever defined a roadmap for
bugfix releases in my life: this kind of roadmap is called "open
critical/major bugs report" in JIRA and it is automatically created
when
filed *bug* reports are confirmed.
james needs to release 2.3.2 together with a road map to stop what
users we have moving to other less sophisticated but more actively
developed servers
Backporting stuff from 3.x to 2.x is simply unfeasible for most
interesting code because we had to change interfaces and break some
compatibility in order to support the new features. I BET
backporting
some of them will take *much* more time than testing trunk as a
whole.
People keep claiming that v2.3 is stable and trunk is not, but
the fact
is that simply no one tested trunk and confirmed it is unstable.
Maybe
it is, but until I'll see bug reports about instability against
trunk I
won't consider this.
i wasn't proposing to backport but to factor out multi-module
libraries which can be shared. bugs can then be fixed against trunk.
components are linked together via interfaces. To factor out modules
that can work in both v2.3 and trunk we have to deal on common
interfaces. The components you talked about rely on changed
interfaces
or define the interfaces used by the rest of james.
yes, there would need to be some glue code back ported. this don't
think that this should be a major issue.
it does mean that the interfaces can be agreed by a release and
versioned independently.
Using karaf doesn't mean you'll depend on it. I think that osgi +
blueprint will be a really good direction to move in.
david jencks
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
