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
