Danny Angus wrote:
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.
I'm happy enough with what JIRA roadmaps give us.
I don't know what exactly you mean with "status file" but I would not
like having more pieces to mantain. It is already boring enough to
manually update the changelog in our website at each release.
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.
I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
I personally don't care of config.xml compatibility: I was just
reporting what I understood was important (and feasible) to the PMC.
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.
Well, don't take me wrong: I never intended to stop you from working on
this. If you have the time and will to do that then feel free to start
some proposal (either with code or discussion as you prefer).
I just would avoid starting discussions on things that have no
"champion" to do the concrete work at the end because I'm running short
in time and I prefer to concentrate on things that I already thought in
past. I admit I didn't think to mailet apis too much but I did this in
past and I wrote something (also in the mailet-api list) and it seems we
(all) have really different ideas about the next mailet apis, so I
decided to avoid the topic to concentrate on something simpler.
Maybe someone receiving less vetoes to proposals ;-) will be more likely
to do this step.
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.
As I said we probably don't agree on the future of the mailet apis ;-)
Beside joking, I believe that now that we are here we should wait to
find a good solution to services to be provided to "handlers plugins"
and maybe the same patterns could be used in the next mailet. I simply
thought at this roadmap because I thought it was convenient:
unfortunately the time is really much less than what I would like to do
on James.
Btw you shouldn't fear me: I rerely use vetoes and always prefer an
average/partial solution to no solution. And I would be really happy to
see some new concrete effort by "less active" committers!
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.
Ok, so if we let pop3 users to have the "@domain" and we add to the
pop3server a configuration for a default domain to be used when no
domain is passed would solve both issues, right?
Now if we want to bind the pop3server to multiple IPs we have to declare
multiple <pop3server> blocks anyway: is this right?
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.
Well, ToMultiRepository try first to retrieve the user inbox via
MailServer.getUserInbox method. IIRC it shouldn't be so hard to isolate
also this method in the new services we added lately. I'll try to
remember this the next time I'll review the code about this issue.
In POP3 people would have to use "[EMAIL PROTECTED]" as login and no more
"user".
Unless you used IP based Vhosting.
Right.
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.
I accept this ;-)
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 :-(
Now it should work again.
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.
Well, as you can see the goals I proposed (and that at least Norman
agreed) was listed on that topic and we have took them seriously enough.
I think that I can't do anything more than proposing a list, finding a
"working crew" sharing the same goals and get things done ;-).
I tried for more than an year to do some bigger planning and bigger
changes but I failed. Even small changes have been vetoed, so I won't
loose much more time on big goals if there is a chance to be vetoed at
the first step. I can leave this task to someone with more social talent
than me with this.
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.
Feel free to do some proposal, but remember that in not paid open source
it is hard to write timetable for others.
I think that Norman and I did exactly a proper plan and almost a proper
timetable because we put on the table tasks that we was willing to do.
I would be happy to start discussing a bigger/better roadmap: anyone
should start writing what they will be willing to work on and when. THen
we can see how to solve the puzzle (and what can be part of James and
what not).
I personally don't have a fixed roadmap: it depends on my mood and
sometimes on what features my clients are willing to pay me for ;-) but
I always try to keep trunk consistent and to commit things only when I
know I can finish it.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
