Danny Angus wrote:
On 10/20/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Slightly more than a month ago I wrote a roadmap, here is an update for
people that has not time for a day to day oversight.
Thanks Stefano ;-)
Can we consider timetabling some other changes now that we've made
such good progress?
Well, I think important things are:
1) don't delay the next release cycle once we added the features we
planned (and currenlty the only missing big piece is handlerapi, imho)
2) don't break the storage compatibility and the config.xml
compatibility (I think we currenlty kept both compatibilities).
1/ One thing I have been trying to get "on the table" for a couple of
years(!) now is a re-write of the mailet API. We need to make the API
support *all* of the functions required by Mailets and a Mailet
container. This means for example that amongst other smaller stuff
some of the service interfaces for repositories need to be sorted and
refactored into the API
Rewriting mailet apis is not a simple task and I think it does not
belong to a "short timed" release like the one we're trying to do. Maybe
the following one.
I think that mailet api changes will need much more efforts and thoughts
and I think we should better delay this to a point where currenct active
committers will have a better overall overview of what services mailets
needs and how to try to fix this.
Furthermore I think we should better wait to have a clean handlerapi
structure because we should try to find a common way to access some of
the services offered by the container from in-protocol handlers and from
mailets.
2/ Another thing I'd like to do would be to sort out IP based v
hosting and nameing convetion v hosting. Effectively certain
per-instance things, like the local repository, become per-vhost, and
local delivery gets to take the name of the repo as a param.
?
d.
I think that we already did the bigger steps to make this possible.
Now it should be easy to alter the services to have a better support for
virtualhosting.
Can you elaborate some concrete solution?
I don't understand the "nameing convetion v hosting" thing: SMTP and
POP3 servers do not receive informations on the name used to reach them,
but only the IP used.
I think that the solution I found out-there to provide easy
out-of-the-box v hosting support is to put "[EMAIL PROTECTED]" into the
UsersRepository and change "LocalDelivery" (ToMultiRepository) to use
the full recipient instead of the recipient.getName() when retrieving
the mailbox.
In POP3 people would have to use "[EMAIL PROTECTED]" as login and no more
"user".
We should also add DomainList service from the UsersRepository so that
James would automatically know what are the local domains by looking the
domains used in the UsersRepository names.
This should be relatively easy to be implemented now that we isolated
most of the services in few clean interfaces.
If my memory is right the only missing piece for this scenario is to
enhance the "ToMultiRepository" to let it use some parameter to define
the repository name.
You can read more at the end of this comment:
https://issues.apache.org/jira/browse/JAMES-414#action_12322582
Imho the key is to split every "big task" in many small tasks because
everyone here fear major changes so we should analyze the "big goal"
(that's why I ask you the concrete goal) and find out if we can do this
with small steps.
Unfortunately there are things that cannot be splitted in small tasks
and we have to delay: I have full DSN support for James waiting since
almost 2 years to be included because it needs a lot of changes in the
core of james and I don't have enough will and time to explain why every
change is needed so I gave up including it.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
