On 5/25/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
Serge,
What did you have in mind when implementing forward and alias as part of the
user repository record? Just the "obvious"? And why both? I'd like some
concept of what you had in mind.
I am asking because when we revise user reposito
Stefano Bagnara wrote:
> Noel J. Bergman wrote:
> > That requires a bit of thought, rather than rushing into coding
> I have lost the count of discussions with no end, with no conclusions
> I'm sure I can find discussions about virtual users at least 3 years old
Actually, the virtual user code
Serge,
What did you have in mind when implementing forward and alias as part of the
user repository record? Just the "obvious"? And why both? I'd like some
concept of what you had in mind.
I am asking because when we revise user repositories, I am wondering if we
should discard those in favor
Noel J. Bergman wrote:
That requires a bit of thought, rather than rushing into coding
I'm against this fear of coding.
Writing code many times takes much less that discussing and it decreases
the misunderstandings because we all share the JVM/Java specification
knowledge.
I have lost the
Steve Brewin wrote:
For me, this is a prime example of why people have said we need to discuss
first, achieve consensus, then act.
In the discussion I would have lost the same amount of time I lost in
creating the first refactoring proposal: now we have a concrete thing to
talk about, not si
[
http://issues.apache.org/jira/browse/JAMES-509?page=comments#action_12413314 ]
Steve Brewin commented on JAMES-509:
For me, this is a prime example of why people have said we need to discuss
first, achieve consensus, then act.
I'm afraid I don't unde
Norman commented:
> a modular virtual hosting support whould be a really nice thing.
> The current way the virtual user table support is not the best.
In what way? Actually, I would say that the current virtual user table code
is in pretty good shape, and is very powerful. The major thing that
Stefano Bagnara wrote:
>
>
> [ http://issues.apache.org/jira/browse/JAMES-509?page=all ]
>
> Stefano Bagnara updated JAMES-509:
> --
>
> Attachment: fetchmail-refactoring1
>
> Just a first step, so people can review...
>
> > Cleanup/Refactor FetchMail
Am Donnerstag, den 25.05.2006, 01:31 +0200 schrieb Stefano Bagnara:
> Noel J. Bergman (JIRA) wrote:
> > [
> > http://issues.apache.org/jira/browse/JAMES-508?page=comments#action_12413193
> > ]
> >
> > Noel J. Bergman commented on JAMES-508:
> > ---
> >
>
Check for valid RCPT before accept email
Key: JAMES-510
URL: http://issues.apache.org/jira/browse/JAMES-510
Project: James
Type: New Feature
Reporter: Norman Maurer
Assigned to: Norman Maurer
We should try to check fo
Same here. We use maven2 for the jspf subproject and im really happy
with it. if we can get sure maven2 can manage all needs i would be +1
for it.
bye
Norman
Am Donnerstag, den 25.05.2006, 09:35 +0100 schrieb Danny Angus:
> I use james at work and it is a very good way of controlling project
> s
Im happy you do this. It takes many time for me too to understand the
code when doing the replacement of the static dnsserver use.
And have the same functionally in a clearer way with not so much code is
perfect.
bye
Norman
Am Donnerstag, den 25.05.2006, 10:20 + schrieb Stefano Bagnara
(JIR
[ http://issues.apache.org/jira/browse/JAMES-509?page=all ]
Stefano Bagnara updated JAMES-509:
--
Attachment: fetchmail-refactoring1
Just a first step, so people can review...
> Cleanup/Refactor FetchMail code
> ---
>
>
Cleanup/Refactor FetchMail code
---
Key: JAMES-509
URL: http://issues.apache.org/jira/browse/JAMES-509
Project: James
Type: Improvement
Components: FetchMail
Versions: 2.4.0
Reporter: Stefano Bagnara
Assigned to: Stefano
I use james at work and it is a very good way of controlling project
structure, (src, docs, tests, everything), I would be +1 to maven if a
POC demonstrated that it meets all of our requirements.
d.
On 25/05/06, Serge Knystautas <[EMAIL PROTECTED]> wrote:
+0. I use ant for everything still. T
15 matches
Mail list logo
