On 10/21/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> 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)
I think perhaps its time we moved to having a status file.
2) don't break the storage compatibility and the config.xml
compatibility (I think we currenlty kept both compatibilities).
Not sure why you're so keen on this as one of only two things. Yes
this is important to end users for ease of upgrade, but it isn't
sacred. Tools can be provided to migrate content and configuration if
necessary.
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.
Yeah I figured. Same as always ;-)
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.
Well "current active" commiters are not everyone, there are still some
of us "less active" people who know and understand the API, what it
can be used for, and how it should be written. and whats more we also
know and understand its weaknesses and flaws.This work needs to be
done, and has been needed for a long time. It will have little effect
on James's mailets.
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.
Not sure I agree, unless the handlerapi is being proposed for adding to mailet.
Theres no reason why the same services shouldn't be available in
different ways, its just a case of wrapping and decorating things.
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.
Yeah, correct. But people keep proposing that POP3 vhosting involve
people logging in with [EMAIL PROTECTED] or some other work-around. this
*is* name based vhosting for pop3, the name is derived from the
log-in, you propose such a solution youself below. The other option is
to bind certain domains to certain IP addresses in the same James
instance.
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.
That locks you into using one repository, I'm proposing that a
different repository can be used per "host" and that hosts can be
distinguished by either IP address or naming convention.
In POP3 people would have to use "[EMAIL PROTECTED]" as login and no more
"user".
Unless you used IP based Vhosting.
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.
Yeah, not 100% sure it would work for all scenarios, but it would be
worth the effort to do the analysis.
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.
Well thats true to some extent. but only if you accept that your
proposal is enough and as far as we'd want to go.
You can read more at the end of this comment:
https://issues.apache.org/jira/browse/JAMES-414#action_12322582
Problem accessing this just now :-(
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.
Yeah OK, but it is necessary to catalogue our goals and do some planning.
Otherwise we get into a rut of making small changes all the time with
no longer term plan.
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.
We'll perhaps the time is right for us to start to perpare some proper
plans. and a proper timetable of releases.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
