Hello Norman You are right, the call to method isEmpty in your patch is for a List not for a String and the RFC is clear enough about the delete and quit command.
So the patch is fine for me. Thanks Manolo On Thu, Mar 25, 2010 at 6:35 PM, Norman Maurer <norman.mau...@googlemail.com> wrote: > Hi Manuel, > > just checked and it compiles without a problem with java 5. > > About the deletion of emails, I just re-readed the rfc on POP3 and I > think the patch does the right thing.. > > From rfc1939: > > > DELE msg > > Arguments: > a message-number (required) which may NOT refer to a > message marked as deleted > > Restrictions: > may only be given in the TRANSACTION state > > Discussion: > The POP3 server marks the message as deleted. Any future > reference to the message-number associated with the message > in a POP3 command generates an error. The POP3 server does > not actually delete the message until the POP3 session > enters the UPDATE state. > > > 6. The UPDATE State > > When the client issues the QUIT command from the TRANSACTION state, > the POP3 session enters the UPDATE state. (Note that if the client > issues the QUIT command from the AUTHORIZATION state, the POP3 > session terminates but does NOT enter the UPDATE state.) > > If a session terminates for some reason other than a client-issued > QUIT command, the POP3 session does NOT enter the UPDATE state and > MUST not remove any messages from the maildrop. > > > Bye, > Norman > > 2010/3/25 Norman Maurer <norman.mau...@googlemail.com>: >> Hi Manuel, >> >> Thx for the comments and for reviewing the stuff. Comments are inside... >> >> 2010/3/25 Manuel Carrasco Moñino <man...@apache.org>: >>> Hi Norman, I''ve tried your patch and it works fine for me. >>> >>> Just a bunch of notes: >>> - It is necessary to uncomment the SieveMailet line to get the mails >>> in the IMAP repository. I suppose this should be the default. >> >> True, I would even rewrite the SieveMailet a bit for this.. But that >> is not a biggy >> >>> - It is supposed that James has to compile with java 1.5, but you are >>> using isEmpty() :-( >> >> Could catch, will replace this once we dedicited to commit the diff >> >>> - I think the name of the "INBOX" has to be provided by the >>> mailboxmanager instead of be hardcoded. >> >> Well INBOX is the default you would use with javamail too. So I don't >> saw this as a big problem .. >> >>> - Another thing is related with the 'DELE' command, messages are >>> marked for deleting, but it seems that they are not deleted until the >>> user does a quit, so in the case of a failure in the connection the >>> messages doesn't go deleted. >> >> I need to reread on this but I thought thats exactly how pop3 is >> supposed to work. In fact this was what the pop3server did before too >> >>> - Also It would be good to add in a next release some parameters like >>> move deleted messages to trash, mark deleted messages as seen, etc, >>> so that users using various MUA don't loose messages. >> >> Thats not the scope of POP3. POP3 doesn't support folders so thats not >> possible. >> >>> >>> I'm glad with the improvement (thanks Norman), so I vote to remove the >>> old mailrepository. >>> >>> Manolo >>> >> >> Thx again for your comments... >> >> >>> >>> >>> On Thu, Mar 25, 2010 at 11:41 AM, Bernd Fondermann >>> <bernd.fonderm...@googlemail.com> wrote: >>>> On Wed, Mar 24, 2010 at 19:47, Norman Maurer <nor...@apache.org> wrote: >>>>> Hi all, >>>>> >>>>> I want to propose some really heavy change in current JAMES trunk, and >>>>> so next version. As all of you knows we are supporting IMAP in current >>>>> development version, which ships with its own mail store backend >>>>> called MailboxManager / Mailbox. For POP3 we use MailRepository as >>>>> backend. >>>>> I think this is a no go for a number of reasons, but the major one is >>>>> that we should be able to switch between IMAP and POP3 without the >>>>> need to migrate mails. So I rewrote the POP3Server to re-use the >>>>> MailboxManager / Mailbox stuff which is used by IMAP. >>>>> >>>>> So if a user login via POP3 he will just see the folder called INBOX >>>>> and nothing else. With IMAP he will see all folders. Thats exactly >>>>> what dovecot and courier does ( both heavy used unix imap/pop3 >>>>> servers). >>>>> Another advance is that we elimate one more dependency on storing >>>>> mails via javamail, which is not the way to go for the future ... >>>>> On the downside we will break backward-compatibility with every James >>>>> release we did before. So we will need to write a "migration" tool, >>>>> but this should not be to hard. >>>>> >>>>> Because the change is so heavy, I dedicited to attach it to JIRA for >>>>> review and not commit it directly. >>>>> >>>>> You can find it here: >>>>> https://issues.apache.org/jira/browse/JAMES-983 >>>>> >>>>> So what do you think ? >>>> >>>> +1 on the proposal, (didn't review the code). >>>> >>>> This is what I suggested a long time ago, (and maybe if I search the >>>> archives I'll find it, but if not than I wish that I would have >>>> suggested it). >>>> >>>> Can you outline why is this such a big change and where the risks are >>>> (except for running faster ;-)? >>>> >>>> Bernd >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org >>>> For additional commands, e-mail: server-dev-h...@james.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org >>> For additional commands, e-mail: server-dev-h...@james.apache.org >>> >>> >> >> >> Bye, >> Norman >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
