Stefano Bagnara wrote:
> Steve Brewin (JIRA) ha scritto:
> > [
> https://issues.apache.org/jira/browse/JAMES-509?page=com.atlas
sian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> >
> > Steve Brewin updated JAMES-509:
> > ---
> >
> > Priority: Minor (w
[
https://issues.apache.org/jira/browse/JAMES-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Brewin updated JAMES-509:
---
Assignee: (was: Stefano Bagnara)
> Cleanup/Refactor FetchMail code
> -
Steve Brewin (JIRA) ha scritto:
[
https://issues.apache.org/jira/browse/JAMES-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Brewin updated JAMES-509:
---
Priority: Minor (was: Major)
Swtched priority from major to minor.
[
https://issues.apache.org/jira/browse/JAMES-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Brewin updated JAMES-509:
---
Priority: Minor (was: Major)
Swtched priority from major to minor.
Stefano, if this is now off your
[ http://issues.apache.org/jira/browse/JAMES-509?page=all ]
Norman Maurer updated JAMES-509:
Fix Version/s: Trunk
(was: Next Major)
Will not go in next major
> Cleanup/Refactor FetchMail code
> ---
>
>
[ http://issues.apache.org/jira/browse/JAMES-509?page=all ]
Norman Maurer updated JAMES-509:
Fix Version: 3.0
(was: 2.4.0)
> Cleanup/Refactor FetchMail code
> ---
>
> Key: JAMES-509
> URL
[ http://issues.apache.org/jira/browse/JAMES-509?page=all ]
Joachim Draeger updated JAMES-509:
--
Attachment: james-imap2-proposal-extended-2.zip
Current source including proposal Interfaces, and xdocs about requirements of a
JDBC Implementation.
Javad
Serge Knystautas wrote:
Stefano,
I'm having trouble determining whether I think this is a helpful
refactoring based on the diffs. Do you have a before and after
view?... maybe ViewSVN link to the point before you started to
changes, and then a download of the source afterward?
If you have a l
Stefano Bagnara wrote:
Bernd Fondermann wrote:
Stefano,
One question: The refactoring you are providing, does it work? (Did
you run it? Did you test all the features and functionality beforehand
and afterwards?)
I already wrote I don't have run james with the refactored version: it
takes
Stefano,
I'm having trouble determining whether I think this is a helpful
refactoring based on the diffs. Do you have a before and after
view?... maybe ViewSVN link to the point before you started to
changes, and then a download of the source afterward?
I like the idea of making the code format
Bernd Fondermann wrote:
Stefano,
One question: The refactoring you are providing, does it work? (Did you
run it? Did you test all the features and functionality beforehand and
afterwards?)
I already wrote I don't have run james with the refactored version: it
takes time to do this things. I
Stefano,
One question: The refactoring you are providing, does it work? (Did you
run it? Did you test all the features and functionality beforehand and
afterwards?)
I agree with Steve that a refactoring is not worth applying if we don't
know if it doesn't breaks something, regardeless how si
I would like to add an example:
In James 2.1 we had FetchPOP
In James 2.2.0 FetchMail has been introduced and FetchPop deprecated.
Fetchmail was a complete rewrite and had no unit tests, and has been
introduced in a minor (2.#) release.
Does this mean that if I rename the refactored code to
Steve Brewin wrote:
As you will have gathered, I don't think this is a good way of proposing a
major change in a component.
What would be a better way? I can't see anything better than the real
code to have concrete discussion.
My main issue is purely practical. I think it seriously unwise
Stefano Bagnara wrote:
>
> Steve Brewin wrote:
> > For me, this is a prime example of why people have said we
> need to discuss first, achieve consensus, then act.
>
>
> I'm sorry if this offend you in any way, I think this is a
> needed thing
> for me to keep working on James, so I did it a
[ http://issues.apache.org/jira/browse/JAMES-509?page=all ]
Stefano Bagnara updated JAMES-509:
--
Attachment: fetchmail-refactoring2
This is an updated version. Not too much differences from the previous, but I
did it, so I think it is better to talk abo
Stefano Bagnara wrote:
To me it's something like obfuscated: I feel worst than browsing
decompiled code ;-)
And here is the pratical example:
Take this code:
-
/**
* Answer if aMessage has been SEEN.
* @param aMessage
* @return boolean
* @throws MessagingException
*/
pro
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
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
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
> ---
>
>
21 matches
Mail list logo
