You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Norman Maurer <no...@apache.org> on 2010/01/20 12:38:09 UTC
MailRepository and MailboxManager
Hi all,
after I already brought this up some time in the past I thought a bit
more about MailRepository and MailboxManager. I'm still in favor to
just use one Repository for IMAP and POP3. I think its a no go to ship
different "storages" for the protocols. I know the requirement for
POP3 and IMAP are totally different but shouldn't it be possible to
write some adapter which will just expose the Mails via the
MailRepository interface but use an underlying MailboxManager to fetch
it ?
So when an User would use IMAP he would get all he features of
MailboxManager, if he use POP3 he will just see the emails in the
Folder INBOX. Thats exactly how many unix mailserver do it. Like
Dovecot, Courier etc. So it can't be the worst idea =P
Then we could mark the old implementations with "@deprecated" and
remove them later, or beeing more radical remove them now.
Mailmigration could just work with the RemoteManager and "movemails"
command.
WDYT ?
I think I remember Robert didn'T like the idea to much in the past..
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Feb 12, 2010 at 10:26 AM, Norman Maurer
<no...@googlemail.com> wrote:
> Sounds good,
>
> so what about some code to show your "general" idea ?
my project has kicked off so i don't have a lot of cycles ATM but i'll
do my best...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
Sounds good,
so what about some code to show your "general" idea ?
Bye,
Norman
2010/2/12 Robert Burrell Donkin <ro...@gmail.com>:
> On Thu, Feb 4, 2010 at 9:08 PM, Norman Maurer
> <no...@googlemail.com> wrote:
>> <SNIP>
>>
>> 2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
>>
>>> maybe:
>>>
>>> deliver(String URL, Mail mail)
>>>
>>> would be a reasonable first step. (i agree that we need to revise Mail
>>> but i think that can wait.)
>>>
>>> URL gives more flexibility for virtual stuff and namespacing. for both
>>> IMAP and POP3 the storage of the read only raw data is logically
>>> independent from the read-write meta-data that's need to manage the
>>> mail. i suspect that the optimal performance would be to combine a
>>> flexible data store for the meta-data and file or http for the raw
>>> data.
>>>
>>> examples
>>>
>>> deliver("james://username@localhost/", mail)
>>>
>>
>> I think we could even use it for deliver via smtp to remote host:
>>
>> deliver("smtp:mail.whatever.de",mail)
>>
>> WDYT ?
>
> sounds good :-)
>
> i like the idea of being able to compose the processor from factored
> out handlers and register them by protocol
>
> opinions?
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Feb 4, 2010 at 9:08 PM, Norman Maurer
<no...@googlemail.com> wrote:
> <SNIP>
>
> 2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
>
>> maybe:
>>
>> deliver(String URL, Mail mail)
>>
>> would be a reasonable first step. (i agree that we need to revise Mail
>> but i think that can wait.)
>>
>> URL gives more flexibility for virtual stuff and namespacing. for both
>> IMAP and POP3 the storage of the read only raw data is logically
>> independent from the read-write meta-data that's need to manage the
>> mail. i suspect that the optimal performance would be to combine a
>> flexible data store for the meta-data and file or http for the raw
>> data.
>>
>> examples
>>
>> deliver("james://username@localhost/", mail)
>>
>
> I think we could even use it for deliver via smtp to remote host:
>
> deliver("smtp:mail.whatever.de",mail)
>
> WDYT ?
sounds good :-)
i like the idea of being able to compose the processor from factored
out handlers and register them by protocol
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
<SNIP>
2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
> maybe:
>
> deliver(String URL, Mail mail)
>
> would be a reasonable first step. (i agree that we need to revise Mail
> but i think that can wait.)
>
> URL gives more flexibility for virtual stuff and namespacing. for both
> IMAP and POP3 the storage of the read only raw data is logically
> independent from the read-write meta-data that's need to manage the
> mail. i suspect that the optimal performance would be to combine a
> flexible data store for the meta-data and file or http for the raw
> data.
>
> examples
>
> deliver("james://username@localhost/", mail)
>
I think we could even use it for deliver via smtp to remote host:
deliver("smtp:mail.whatever.de",mail)
WDYT ?
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jan 22, 2010 at 1:13 PM, Norman Maurer
<no...@googlemail.com> wrote:
> 2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
<snip>
>>>> 4. there are subtle semantic differences between the meanings of flags
>>>> in POP3, SMTP and IMAP
>>>>
>>>
>>> SMTP Flags ? You lost me here..
>>
>> IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but
>> not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics
>> from IMAP's delete so separate flags are needed. (i suspect that most
>> users wouldn't expect mail to disappear from IMAP just because a mail
>> client has been configured with autodeletion.)
>
> You lost me here.. IMAP sets flags based on SMTP ? I don't get it...
it's not important and not worth explaining since it's not a problem
without javamail
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
> On Fri, Jan 22, 2010 at 8:02 AM, Norman Maurer
> <no...@googlemail.com> wrote:
>> Hi Robert,
>>
>> comments inside..
>
> true :-)
>
>> 2010/1/21 Robert Burrell Donkin <ro...@gmail.com>:
>>> On Thu, Jan 21, 2010 at 4:27 PM, Norman Maurer <no...@apache.org> wrote:
>
> <snip>
>
>>> here's the issues which spring to mind:
>>>
>>> 1. the POP3 protocol stuff is sound enough but MailRepository insists
>>> on instantiating heavy mail objects which kills performance for IMAP
>>> (my server died several times a day before i ripped out this feature)
>>
>> Thats true. I even don't think we need a Mail object at all for
>> serving email via POP3. Because we just need the "raw" email and
>> nothing more..
>
> transforming via standard JavaMail (rather than Stefano's amazing
> workaround) alters the email so that SMTP->IMAP delivery is no longer
> specification compliant. i suspect the same goes for POP3.
True.. I would prefer to just "/dev/null" the whole javamail crap ;)
For SMTP sending (RemoteDelivery) I would be very interested in see an
MINA base delivery mailet ....
>
>>> 2. the MailRepository allows actions which are incompatible with IMAP.
>>> (IMAP relies on the actual mail being read only with meta data
>>> including flags being read write.)
>>>
>>> 3. IMAP requires parsing supported by Mime4J which is incompatible
>>> with javax mail
>>>
>>
>> To be hornest, I don't like the whole javamail stuff to much. My
>> "vision" of new-geneneration james would be to not use javamail at
>> all. Javamail is just to "strict" of rfc validations etc and sucks in
>> terms of performance ( thats why we introduced all the wrappers to
>> lazy load stuff).
>
> +1
>
> mime4j allows read only streaming partial pull parsing. most mailets
> just look at headers so this would be much more efficient and stop
> james dying when presented with a huge email. given mina, this would
> allow mail processing to begin before the mail is accepted and would
> allow unification between the micro mailets used by SMTP and mailets
> in the pipeline.
+1. The Problem would be the break of the Mailet API. Maybe we can
just add a wrapper to allow the stuff which depends on javamail to
still work..
>
>>> 4. there are subtle semantic differences between the meanings of flags
>>> in POP3, SMTP and IMAP
>>>
>>
>> SMTP Flags ? You lost me here..
>
> IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but
> not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics
> from IMAP's delete so separate flags are needed. (i suspect that most
> users wouldn't expect mail to disappear from IMAP just because a mail
> client has been configured with autodeletion.)
You lost me here.. IMAP sets flags based on SMTP ? I don't get it...
>
>>> 5. there are subtle differences in rules between a POP3 INBOX and an
>>> IMAP INBOX. not a problem to resolve but the code needs to understand
>>> whether it's been used for IMAP or POP3 so it can behaviour correctly.
>>> i think that this prevents the use of a single functional API.
>>>
>>> my thinking is along the lines of:
>>
>> True enough..
>
> :-)
>
>>> 1. introducing a new messaging style interface specifically for mail delivery
>>
>> +1
>
> maybe:
>
> deliver(String URL, Mail mail)
>
> would be a reasonable first step. (i agree that we need to revise Mail
> but i think that can wait.)
>
> URL gives more flexibility for virtual stuff and namespacing. for both
> IMAP and POP3 the storage of the read only raw data is logically
> independent from the read-write meta-data that's need to manage the
> mail. i suspect that the optimal performance would be to combine a
> flexible data store for the meta-data and file or http for the raw
> data.
>
> examples
>
> deliver("james://username@localhost/", mail)
>
> delivers the mail to account username
>
> deliver("jcr://username:password@bilbo.lan/general", mail)
>
> would be available to represent the delivery of a message to a JCR
> serving from bilbo.lan using a connection with user "username" and
> password "password" into the general space
>
> deliver("http://username:password@bilbo.lan/robert.donkin", mail)
>
> and this would be available to represent the delivery of a message to
> a RESTful server (eg the blindingly fast CouchDB) at bilbo.lan using a
> connection with user "username" and password "password" POSTing to the
> robert.donkin URL.
>
> deliver("maildir:///rdonkin", mail)
>
> and this would be available to represent the delivery of a message
> into a mail directory on the local host with relative path rdonkin
>
Sounds good :)
>>> 2. introduce an efficient, simple, streaming POP3 backend API which
>>> can be adapted to MailRepository or other mailbox designs. performance
>>> for MailRepository would still suck but the OpenJPA (and potentially
>>> JCR) backends from IMAP could be used without heavy adaption or
>>> performance loss.
>>
>> +1
>
> great :-)
>
> shall i take a look at this?
>
Yeah please...
>>> 3. add full support for flags to IMAP. use custom flags to support
>>> POP3 mailboxing correctly.
>>>
>>
>> +1
>
> i wonder whether we should ditch Flags from JavaMail and just roll our own
>
Depending on javamail just for flags sounds like something
"suboptimal". Lets roll our own..
>>> so, we'd lose a general interface but gain interoperability between
>>> the protocols.
>>>
>>> - robert
>>>
>>
>> Sounds really good..
>
> great
>
> - robert
>
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
To keep this alive..
I really like the idea of having some kind of "easy" interface.
Something like Stefano and Robert suggest. Any of you have some kind
of "component graph" to layout the idea ?
Bye,
Norman
2010/1/25 Norman Maurer <no...@googlemail.com>:
> Urgh... ok good luck then!
>
> Bye,
> Norman
>
>
> 2010/1/25 Robert Burrell Donkin <ro...@gmail.com>:
>> On Mon, Jan 25, 2010 at 11:46 AM, Norman Maurer
>> <no...@googlemail.com> wrote:
>>> Ok..
>>>
>>> I just asked because it would be really helpful to have your help here
>>> before you need to concentrate on your study again ;)
>>
>> something unexpected cropped up at the end of last week as soon as i'd
>> finished my exam (don't ask) :-/
>>
>> i'll do my best but i can't promise
>>
>> - robert
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
Urgh... ok good luck then!
Bye,
Norman
2010/1/25 Robert Burrell Donkin <ro...@gmail.com>:
> On Mon, Jan 25, 2010 at 11:46 AM, Norman Maurer
> <no...@googlemail.com> wrote:
>> Ok..
>>
>> I just asked because it would be really helpful to have your help here
>> before you need to concentrate on your study again ;)
>
> something unexpected cropped up at the end of last week as soon as i'd
> finished my exam (don't ask) :-/
>
> i'll do my best but i can't promise
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Jan 25, 2010 at 11:46 AM, Norman Maurer
<no...@googlemail.com> wrote:
> Ok..
>
> I just asked because it would be really helpful to have your help here
> before you need to concentrate on your study again ;)
something unexpected cropped up at the end of last week as soon as i'd
finished my exam (don't ask) :-/
i'll do my best but i can't promise
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
Ok..
I just asked because it would be really helpful to have your help here
before you need to concentrate on your study again ;)
Bye,
Norman
2010/1/25 Robert Burrell Donkin <ro...@gmail.com>:
> On Mon, Jan 25, 2010 at 9:58 AM, Norman Maurer
> <no...@googlemail.com> wrote:
>> So any takers on this ?
>>
>> Robert ?
>
> some stuff's turned up which i need to sort out (i'm doing the NNTP
> stuff since no concentration's needed). i'd like to at least document
> the design but it depends on how things work out. if it can wait a day
> or two, it should be clearer then.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Jan 25, 2010 at 9:58 AM, Norman Maurer
<no...@googlemail.com> wrote:
> So any takers on this ?
>
> Robert ?
some stuff's turned up which i need to sort out (i'm doing the NNTP
stuff since no concentration's needed). i'd like to at least document
the design but it depends on how things work out. if it can wait a day
or two, it should be clearer then.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
So any takers on this ?
Robert ?
Bye,
Norman
2010/1/22 Norman Maurer <no...@googlemail.com>:
> configurable is fine...
>
> Bye,
> Norman
>
>
> 2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
>> On Fri, Jan 22, 2010 at 1:44 PM, Norman Maurer
>> <no...@googlemail.com> wrote:
>>> 2010/1/22 Stefano Bagnara <ap...@bago.org>:
>>>> 2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
>>>
>>> </SNIP>
>>>>>
>>>>> IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but
>>>>> not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics
>>>>> from IMAP's delete so separate flags are needed. (i suspect that most
>>>>> users wouldn't expect mail to disappear from IMAP just because a mail
>>>>> client has been configured with autodeletion.)
>>>>
>>>> Great! I never thought at this. So you say that a single user
>>>> "mailstore" accessed with both IMAP and POP3 should not delete email
>>>> when accessed via pop3 with the delete on ? I don't know how other
>>>> products work with this regard: have you done any "survey" ? The only
>>>> one I know is Gmail and when you delete in POP3 it doesn't indeed
>>>> deletes your email for real. This is not only a change in the
>>>> "interface" of the repository but also a change in the functional
>>>> behaviour of the repository (or of our pop3 implementation).
>>>> (I'm not against, this, just trying to collect requirements, ideas).
>>>>
>>>
>>> In dovecot and courier when you delete an email via pop3 its gone.. I
>>> think thats the right solution.
>>
>> this solution causes issues for IMAP clients
>>
>> for practical reasons, clients like thunderbird need some folders to
>> be non-compliant with the IMAP spec (eg "Sent"). so, i think this
>> would work best as a configurable option so admins could decide
>> whether POP3 would really delete or just mark deleted.
>>
>> - robert
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
configurable is fine...
Bye,
Norman
2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
> On Fri, Jan 22, 2010 at 1:44 PM, Norman Maurer
> <no...@googlemail.com> wrote:
>> 2010/1/22 Stefano Bagnara <ap...@bago.org>:
>>> 2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
>>
>> </SNIP>
>>>>
>>>> IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but
>>>> not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics
>>>> from IMAP's delete so separate flags are needed. (i suspect that most
>>>> users wouldn't expect mail to disappear from IMAP just because a mail
>>>> client has been configured with autodeletion.)
>>>
>>> Great! I never thought at this. So you say that a single user
>>> "mailstore" accessed with both IMAP and POP3 should not delete email
>>> when accessed via pop3 with the delete on ? I don't know how other
>>> products work with this regard: have you done any "survey" ? The only
>>> one I know is Gmail and when you delete in POP3 it doesn't indeed
>>> deletes your email for real. This is not only a change in the
>>> "interface" of the repository but also a change in the functional
>>> behaviour of the repository (or of our pop3 implementation).
>>> (I'm not against, this, just trying to collect requirements, ideas).
>>>
>>
>> In dovecot and courier when you delete an email via pop3 its gone.. I
>> think thats the right solution.
>
> this solution causes issues for IMAP clients
>
> for practical reasons, clients like thunderbird need some folders to
> be non-compliant with the IMAP spec (eg "Sent"). so, i think this
> would work best as a configurable option so admins could decide
> whether POP3 would really delete or just mark deleted.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jan 22, 2010 at 1:44 PM, Norman Maurer
<no...@googlemail.com> wrote:
> 2010/1/22 Stefano Bagnara <ap...@bago.org>:
>> 2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
>
> </SNIP>
>>>
>>> IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but
>>> not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics
>>> from IMAP's delete so separate flags are needed. (i suspect that most
>>> users wouldn't expect mail to disappear from IMAP just because a mail
>>> client has been configured with autodeletion.)
>>
>> Great! I never thought at this. So you say that a single user
>> "mailstore" accessed with both IMAP and POP3 should not delete email
>> when accessed via pop3 with the delete on ? I don't know how other
>> products work with this regard: have you done any "survey" ? The only
>> one I know is Gmail and when you delete in POP3 it doesn't indeed
>> deletes your email for real. This is not only a change in the
>> "interface" of the repository but also a change in the functional
>> behaviour of the repository (or of our pop3 implementation).
>> (I'm not against, this, just trying to collect requirements, ideas).
>>
>
> In dovecot and courier when you delete an email via pop3 its gone.. I
> think thats the right solution.
this solution causes issues for IMAP clients
for practical reasons, clients like thunderbird need some folders to
be non-compliant with the IMAP spec (eg "Sent"). so, i think this
would work best as a configurable option so admins could decide
whether POP3 would really delete or just mark deleted.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
2010/1/22 Stefano Bagnara <ap...@bago.org>:
> 2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
</SNIP>
>>
>> IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but
>> not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics
>> from IMAP's delete so separate flags are needed. (i suspect that most
>> users wouldn't expect mail to disappear from IMAP just because a mail
>> client has been configured with autodeletion.)
>
> Great! I never thought at this. So you say that a single user
> "mailstore" accessed with both IMAP and POP3 should not delete email
> when accessed via pop3 with the delete on ? I don't know how other
> products work with this regard: have you done any "survey" ? The only
> one I know is Gmail and when you delete in POP3 it doesn't indeed
> deletes your email for real. This is not only a change in the
> "interface" of the repository but also a change in the functional
> behaviour of the repository (or of our pop3 implementation).
> (I'm not against, this, just trying to collect requirements, ideas).
>
In dovecot and courier when you delete an email via pop3 its gone.. I
think thats the right solution.
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Problem building with eclipse/ maven-surefire-plugin is
missing!!!
Posted by Norman Maurer <no...@googlemail.com>.
Hi Robert,
are you sure you are using the latest trunk ? Try svn update to get
the lastest code. With current trunk all tests pass without problems..
See:
http://hudson.zones.apache.org/hudson/view/James/job/james-server-trunk-m2/
Bye,
Norman
2010/1/26 Robert L. Gurule <rg...@lanl.gov>:
> This is what I got when i built it with "mvn -U clean package"
>
>
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.apache.james.userrepository.MockUsersRepositoryTest
> Tests run: 7, Failures: 0, Errors: 7, Skipped: 0, Time elapsed: 0.062 sec
> <<< FA
> ILURE!
>
> Results :
>
> Tests in error:
> testUsersRepositoryEmpty(org.apache.james.userrepository.MockUsersRepositoryTe
> st)
> testAddUserOnce(org.apache.james.userrepository.MockUsersRepositoryTest)
> testUserAddedIsFound(org.apache.james.userrepository.MockUsersRepositoryTest)
> testUserListing(org.apache.james.userrepository.MockUsersRepositoryTest)
> testUserPassword(org.apache.james.userrepository.MockUsersRepositoryTest)
> testUserAddRemoveCycle(org.apache.james.userrepository.MockUsersRepositoryTest
> )
> testCaseInsensitivesMethods(org.apache.james.userrepository.MockUsersRepositor
> yTest)
>
> Tests run: 7, Failures: 0, Errors: 7, Skipped: 0
>
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to C:\Documents and Settings\106052\My
> Documents\James\james-server
> \user-library\target\surefire-reports for the individual test results.
> [INFO]
> ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 14 seconds
> [INFO] Finished at: Tue Jan 26 12:00:09 MST 2010
> [INFO] Final Memory: 51M/63M
> [INFO]
> ------------------------------------------------------------------------
>
>
>
>> Hi Robert,
>>
>> could you try to run "mvn -U clean package" ?
>>
>> Thx,
>> Norman
>>
>> 2010/1/25 Robert L. Gurule <rg...@lanl.gov>:
>>> I get an error while building it looks like it's looking for the
>>> maven-surefire-plugin...
>>>
>>> any ideas?
>>>
>>> [INFO] Apache JAMES Server User Library ...................... FAILED
>>> [3.203s]
>>> [
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [ERROR]
>>>
>>> Mojo:
>>>
>>> org.apache.maven.plugins:maven-surefire-plugin:2.4.3:test
>>>
>>> FAILED for project:
>>>
>>> org.apache.james:james-server-user-library:jar:3.0-M1
>>>
>>> Reason:
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Problem building with eclipse/ maven-surefire-plugin is
missing!!!
Posted by "Robert L. Gurule" <rg...@lanl.gov>.
This is what I got when i built it with "mvn -U clean package"
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.apache.james.userrepository.MockUsersRepositoryTest
Tests run: 7, Failures: 0, Errors: 7, Skipped: 0, Time elapsed: 0.062 sec
<<< FA
ILURE!
Results :
Tests in error:
testUsersRepositoryEmpty(org.apache.james.userrepository.MockUsersRepositoryTe
st)
testAddUserOnce(org.apache.james.userrepository.MockUsersRepositoryTest)
testUserAddedIsFound(org.apache.james.userrepository.MockUsersRepositoryTest)
testUserListing(org.apache.james.userrepository.MockUsersRepositoryTest)
testUserPassword(org.apache.james.userrepository.MockUsersRepositoryTest)
testUserAddRemoveCycle(org.apache.james.userrepository.MockUsersRepositoryTest
)
testCaseInsensitivesMethods(org.apache.james.userrepository.MockUsersRepositor
yTest)
Tests run: 7, Failures: 0, Errors: 7, Skipped: 0
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] There are test failures.
Please refer to C:\Documents and Settings\106052\My
Documents\James\james-server
\user-library\target\surefire-reports for the individual test results.
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 14 seconds
[INFO] Finished at: Tue Jan 26 12:00:09 MST 2010
[INFO] Final Memory: 51M/63M
[INFO]
------------------------------------------------------------------------
> Hi Robert,
>
> could you try to run "mvn -U clean package" ?
>
> Thx,
> Norman
>
> 2010/1/25 Robert L. Gurule <rg...@lanl.gov>:
>> I get an error while building it looks like it's looking for the
>> maven-surefire-plugin...
>>
>> any ideas?
>>
>> [INFO] Apache JAMES Server User Library ...................... FAILED
>> [3.203s]
>> [
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR]
>>
>> Mojo:
>>
>> org.apache.maven.plugins:maven-surefire-plugin:2.4.3:test
>>
>> FAILED for project:
>>
>> org.apache.james:james-server-user-library:jar:3.0-M1
>>
>> Reason:
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Problem building with eclipse/ maven-surefire-plugin is
missing!!!
Posted by Norman Maurer <no...@googlemail.com>.
Hi Robert,
could you try to run "mvn -U clean package" ?
Thx,
Norman
2010/1/25 Robert L. Gurule <rg...@lanl.gov>:
> I get an error while building it looks like it's looking for the
> maven-surefire-plugin...
>
> any ideas?
>
> [INFO] Apache JAMES Server User Library ...................... FAILED
> [3.203s]
> [
> [INFO]
> ------------------------------------------------------------------------
> [ERROR]
>
> Mojo:
>
> org.apache.maven.plugins:maven-surefire-plugin:2.4.3:test
>
> FAILED for project:
>
> org.apache.james:james-server-user-library:jar:3.0-M1
>
> Reason:
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Problem building with eclipse/ maven-surefire-plugin is missing!!!
Posted by "Robert L. Gurule" <rg...@lanl.gov>.
I get an error while building it looks like it's looking for the
maven-surefire-plugin...
any ideas?
[INFO] Apache JAMES Server User Library ...................... FAILED
[3.203s]
[
[INFO]
------------------------------------------------------------------------
[ERROR]
Mojo:
org.apache.maven.plugins:maven-surefire-plugin:2.4.3:test
FAILED for project:
org.apache.james:james-server-user-library:jar:3.0-M1
Reason:
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Problems building James and How do I run James server 3.0???
Posted by Norman Maurer <no...@googlemail.com>.
Hi Robert,
just click on :
Run As -> Maven package
That should do the trick..
Bye,
Norman
2010/1/22 Robert L. Gurule <rg...@lanl.gov>:
> Hi James,
> If I get a successfull build how do I run James-server 3.0 Imap?
>
> The circumstances are:
>
> I'm using eclipse and M2Eclipse, I when I use the command
> Debug-generate sources I get successfull build, when I use Debug- Maven
> Build i get the following:
>
>
> [ERROR]
>
> The following mojo encountered an error while executing:
> Group-Id: org.apache.maven.plugins
> Artifact-Id: maven-remote-resources-plugin
> Version: 1.1
> Mojo: process
> brought in via: POM
>
> While building project:
> Group-Id: org.apache.james
> Artifact-Id: james-server-core-function
> Version: 3.0-M1
> From file: C:\Documents and Settings\106052\My
> Documents\james\maven.1264004763546\james-server\core-function\pom.xml
> Reason: Failed to resolve dependencies for one or more projects in the
> reactor. Reason: Missing:
> ----------
> 1) org.apache.james:james-server-core-library:test-jar:tests:3.0-M1
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.james
> -DartifactId=james-server-core-library -Dversion=3.0-M1
> -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file
>
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=org.apache.james
> -DartifactId=james-server-core-library -Dversion=3.0-M1
> -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file
> -Durl=[url] -DrepositoryId=[id]
>
> Path to dependency:
> 1) org.apache.james:james-server-core-function:jar:3.0-M1
> 2) org.apache.james:james-server-core-library:test-jar:tests:3.0-M1
>
> ----------
> 1 required artifact is missing.
>
> for artifact:
> org.apache.james:james-server-core-function:jar:3.0-M1
>
> from the specified remote repositories:
> apache.snapshots (http://repository.apache.org/snapshots),
> module-local (file://stage),
> maven2-repository.dev.java.net (http://download.java.net/maven/2/),
> central (http://repo1.maven.org/maven2)
>
> Thanks,
>
> Robert
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Problems building James and How do I run James server 3.0???
Posted by "Robert L. Gurule" <rg...@lanl.gov>.
Hi James,
If I get a successfull build how do I run James-server 3.0 Imap?
The circumstances are:
I'm using eclipse and M2Eclipse, I when I use the command
Debug-generate sources I get successfull build, when I use Debug- Maven
Build i get the following:
[ERROR]
The following mojo encountered an error while executing:
Group-Id: org.apache.maven.plugins
Artifact-Id: maven-remote-resources-plugin
Version: 1.1
Mojo: process
brought in via: POM
While building project:
Group-Id: org.apache.james
Artifact-Id: james-server-core-function
Version: 3.0-M1
>From file: C:\Documents and Settings\106052\My
Documents\james\maven.1264004763546\james-server\core-function\pom.xml
Reason: Failed to resolve dependencies for one or more projects in the
reactor. Reason: Missing:
----------
1) org.apache.james:james-server-core-library:test-jar:tests:3.0-M1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.james
-DartifactId=james-server-core-library -Dversion=3.0-M1
-Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=org.apache.james
-DartifactId=james-server-core-library -Dversion=3.0-M1
-Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file
-Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.james:james-server-core-function:jar:3.0-M1
2) org.apache.james:james-server-core-library:test-jar:tests:3.0-M1
----------
1 required artifact is missing.
for artifact:
org.apache.james:james-server-core-function:jar:3.0-M1
from the specified remote repositories:
apache.snapshots (http://repository.apache.org/snapshots),
module-local (file://stage),
maven2-repository.dev.java.net (http://download.java.net/maven/2/),
central (http://repo1.maven.org/maven2)
Thanks,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Stefano Bagnara <ap...@bago.org>.
2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
> On Fri, Jan 22, 2010 at 1:20 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> So this "deliver" method is something you would add also to the
>> MailetContext, or something different?
>
> dunno
>
> i'd be inclined just to use spring or guice to assemble it into the
> mailets and leave context unchanged
This would mean mailets are injected with a "DeliveryService" (in
addition to MailetContext) ? If I understand it right I'm not sure
this will give us any advantage compared to simply add that "deliver"
method to the api (to MailetContext).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jan 22, 2010 at 1:20 PM, Stefano Bagnara <ap...@bago.org> wrote:
> 2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
>> transforming via standard JavaMail (rather than Stefano's amazing
>> workaround) alters the email so that SMTP->IMAP delivery is no longer
>> specification compliant. i suspect the same goes for POP3.
>
> I'd like to add that in the last Javamail versions (1.4.2, 1.4.3)
> things improved a lot, but anyway, I see many issue expecially wrt
> Activation stuff that makes the whole thing too much "breakable" by
> simply adding some library including a mailcap or similar stuff. As
> mime parsing is so important to our architecture I think it is a good
> choince anyway to use mime4j, even if this means more work initially.
true
>> mime4j allows read only streaming partial pull parsing. most mailets
>> just look at headers so this would be much more efficient and stop
>> james dying when presented with a huge email. given mina, this would
>> allow mail processing to begin before the mail is accepted and would
>> allow unification between the micro mailets used by SMTP and mailets
>> in the pipeline.
>
> This is something I would be very interested. What is processed "in
> protocol" and what is processed asynchronously in the spool should be
> mainly a configuration choice.
sounds about right
>>>> 4. there are subtle semantic differences between the meanings of flags
>>>> in POP3, SMTP and IMAP
>>>
>>> SMTP Flags ? You lost me here..
>>
>> IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but
>> not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics
>> from IMAP's delete so separate flags are needed. (i suspect that most
>> users wouldn't expect mail to disappear from IMAP just because a mail
>> client has been configured with autodeletion.)
>
> Great! I never thought at this. So you say that a single user
> "mailstore" accessed with both IMAP and POP3 should not delete email
> when accessed via pop3 with the delete on ? I don't know how other
> products work with this regard: have you done any "survey" ? The only
> one I know is Gmail and when you delete in POP3 it doesn't indeed
> deletes your email for real. This is not only a change in the
> "interface" of the repository but also a change in the functional
> behaviour of the repository (or of our pop3 implementation).
> (I'm not against, this, just trying to collect requirements, ideas).
the idea would be to only support POP3+IMAP only with the new IMAP
stores and not support POP3+IMAP for the MailRepository stores
>> maybe:
>>
>> deliver(String URL, Mail mail)
>>
>> would be a reasonable first step. (i agree that we need to revise Mail
>> but i think that can wait.)
>
> I'm a fan of first steps :-) Usually the first step is always the more
> difficult. Once we learn to make the first it will be easy to move
> forward and back: one day we'll dance, too.
>
>> deliver("james://username@localhost/", mail)
>> [...]
>> deliver("jcr://username:password@bilbo.lan/general", mail)
>> [...]
>> deliver("http://username:password@bilbo.lan/robert.donkin", mail)
>> [...]
>> deliver("maildir:///rdonkin", mail)
>
> So this "deliver" method is something you would add also to the
> MailetContext, or something different?
dunno
i'd be inclined just to use spring or guice to assemble it into the
mailets and leave context unchanged
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Stefano Bagnara <ap...@bago.org>.
2010/1/22 Robert Burrell Donkin <ro...@gmail.com>:
> transforming via standard JavaMail (rather than Stefano's amazing
> workaround) alters the email so that SMTP->IMAP delivery is no longer
> specification compliant. i suspect the same goes for POP3.
I'd like to add that in the last Javamail versions (1.4.2, 1.4.3)
things improved a lot, but anyway, I see many issue expecially wrt
Activation stuff that makes the whole thing too much "breakable" by
simply adding some library including a mailcap or similar stuff. As
mime parsing is so important to our architecture I think it is a good
choince anyway to use mime4j, even if this means more work initially.
> mime4j allows read only streaming partial pull parsing. most mailets
> just look at headers so this would be much more efficient and stop
> james dying when presented with a huge email. given mina, this would
> allow mail processing to begin before the mail is accepted and would
> allow unification between the micro mailets used by SMTP and mailets
> in the pipeline.
This is something I would be very interested. What is processed "in
protocol" and what is processed asynchronously in the spool should be
mainly a configuration choice.
>>> 4. there are subtle semantic differences between the meanings of flags
>>> in POP3, SMTP and IMAP
>>
>> SMTP Flags ? You lost me here..
>
> IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but
> not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics
> from IMAP's delete so separate flags are needed. (i suspect that most
> users wouldn't expect mail to disappear from IMAP just because a mail
> client has been configured with autodeletion.)
Great! I never thought at this. So you say that a single user
"mailstore" accessed with both IMAP and POP3 should not delete email
when accessed via pop3 with the delete on ? I don't know how other
products work with this regard: have you done any "survey" ? The only
one I know is Gmail and when you delete in POP3 it doesn't indeed
deletes your email for real. This is not only a change in the
"interface" of the repository but also a change in the functional
behaviour of the repository (or of our pop3 implementation).
(I'm not against, this, just trying to collect requirements, ideas).
> maybe:
>
> deliver(String URL, Mail mail)
>
> would be a reasonable first step. (i agree that we need to revise Mail
> but i think that can wait.)
I'm a fan of first steps :-) Usually the first step is always the more
difficult. Once we learn to make the first it will be easy to move
forward and back: one day we'll dance, too.
> deliver("james://username@localhost/", mail)
> [...]
> deliver("jcr://username:password@bilbo.lan/general", mail)
> [...]
> deliver("http://username:password@bilbo.lan/robert.donkin", mail)
> [...]
> deliver("maildir:///rdonkin", mail)
So this "deliver" method is something you would add also to the
MailetContext, or something different?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jan 22, 2010 at 8:02 AM, Norman Maurer
<no...@googlemail.com> wrote:
> Hi Robert,
>
> comments inside..
true :-)
> 2010/1/21 Robert Burrell Donkin <ro...@gmail.com>:
>> On Thu, Jan 21, 2010 at 4:27 PM, Norman Maurer <no...@apache.org> wrote:
<snip>
>> here's the issues which spring to mind:
>>
>> 1. the POP3 protocol stuff is sound enough but MailRepository insists
>> on instantiating heavy mail objects which kills performance for IMAP
>> (my server died several times a day before i ripped out this feature)
>
> Thats true. I even don't think we need a Mail object at all for
> serving email via POP3. Because we just need the "raw" email and
> nothing more..
transforming via standard JavaMail (rather than Stefano's amazing
workaround) alters the email so that SMTP->IMAP delivery is no longer
specification compliant. i suspect the same goes for POP3.
>> 2. the MailRepository allows actions which are incompatible with IMAP.
>> (IMAP relies on the actual mail being read only with meta data
>> including flags being read write.)
>>
>> 3. IMAP requires parsing supported by Mime4J which is incompatible
>> with javax mail
>>
>
> To be hornest, I don't like the whole javamail stuff to much. My
> "vision" of new-geneneration james would be to not use javamail at
> all. Javamail is just to "strict" of rfc validations etc and sucks in
> terms of performance ( thats why we introduced all the wrappers to
> lazy load stuff).
+1
mime4j allows read only streaming partial pull parsing. most mailets
just look at headers so this would be much more efficient and stop
james dying when presented with a huge email. given mina, this would
allow mail processing to begin before the mail is accepted and would
allow unification between the micro mailets used by SMTP and mailets
in the pipeline.
>> 4. there are subtle semantic differences between the meanings of flags
>> in POP3, SMTP and IMAP
>>
>
> SMTP Flags ? You lost me here..
IMAP sets flags based on SMTP. JavaMail sets flags based on SMTP but
not compatibly. IMAP-vs-POP3 eg POP3 delete has different semantics
from IMAP's delete so separate flags are needed. (i suspect that most
users wouldn't expect mail to disappear from IMAP just because a mail
client has been configured with autodeletion.)
>> 5. there are subtle differences in rules between a POP3 INBOX and an
>> IMAP INBOX. not a problem to resolve but the code needs to understand
>> whether it's been used for IMAP or POP3 so it can behaviour correctly.
>> i think that this prevents the use of a single functional API.
>>
>> my thinking is along the lines of:
>
> True enough..
:-)
>> 1. introducing a new messaging style interface specifically for mail delivery
>
> +1
maybe:
deliver(String URL, Mail mail)
would be a reasonable first step. (i agree that we need to revise Mail
but i think that can wait.)
URL gives more flexibility for virtual stuff and namespacing. for both
IMAP and POP3 the storage of the read only raw data is logically
independent from the read-write meta-data that's need to manage the
mail. i suspect that the optimal performance would be to combine a
flexible data store for the meta-data and file or http for the raw
data.
examples
deliver("james://username@localhost/", mail)
delivers the mail to account username
deliver("jcr://username:password@bilbo.lan/general", mail)
would be available to represent the delivery of a message to a JCR
serving from bilbo.lan using a connection with user "username" and
password "password" into the general space
deliver("http://username:password@bilbo.lan/robert.donkin", mail)
and this would be available to represent the delivery of a message to
a RESTful server (eg the blindingly fast CouchDB) at bilbo.lan using a
connection with user "username" and password "password" POSTing to the
robert.donkin URL.
deliver("maildir:///rdonkin", mail)
and this would be available to represent the delivery of a message
into a mail directory on the local host with relative path rdonkin
>> 2. introduce an efficient, simple, streaming POP3 backend API which
>> can be adapted to MailRepository or other mailbox designs. performance
>> for MailRepository would still suck but the OpenJPA (and potentially
>> JCR) backends from IMAP could be used without heavy adaption or
>> performance loss.
>
> +1
great :-)
shall i take a look at this?
>> 3. add full support for flags to IMAP. use custom flags to support
>> POP3 mailboxing correctly.
>>
>
> +1
i wonder whether we should ditch Flags from JavaMail and just roll our own
>> so, we'd lose a general interface but gain interoperability between
>> the protocols.
>>
>> - robert
>>
>
> Sounds really good..
great
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
Hi Robert,
comments inside..
2010/1/21 Robert Burrell Donkin <ro...@gmail.com>:
> On Thu, Jan 21, 2010 at 4:27 PM, Norman Maurer <no...@apache.org> wrote:
>> Sure, I would be very interested in discuss stuff.
>
> cool
>
>> I was just looking for a quick solution which give users who use James
>> 2.3 not to much headach.
>
> i think that should be possible
>
> i think that using sieve to deliver IMAP mail is wrong. i think that
> the script should set attributes on the mail (for example, set a
> attribute for folder) and with independent delivery.
>
>> But I think you are right, the current MailRepository stuff is really
>> bad in terms of Performance.
>
> here's the issues which spring to mind:
>
> 1. the POP3 protocol stuff is sound enough but MailRepository insists
> on instantiating heavy mail objects which kills performance for IMAP
> (my server died several times a day before i ripped out this feature)
Thats true. I even don't think we need a Mail object at all for
serving email via POP3. Because we just need the "raw" email and
nothing more..
>
> 2. the MailRepository allows actions which are incompatible with IMAP.
> (IMAP relies on the actual mail being read only with meta data
> including flags being read write.)
>
> 3. IMAP requires parsing supported by Mime4J which is incompatible
> with javax mail
>
To be hornest, I don't like the whole javamail stuff to much. My
"vision" of new-geneneration james would be to not use javamail at
all. Javamail is just to "strict" of rfc validations etc and sucks in
terms of performance ( thats why we introduced all the wrappers to
lazy load stuff).
> 4. there are subtle semantic differences between the meanings of flags
> in POP3, SMTP and IMAP
>
SMTP Flags ? You lost me here..
> 5. there are subtle differences in rules between a POP3 INBOX and an
> IMAP INBOX. not a problem to resolve but the code needs to understand
> whether it's been used for IMAP or POP3 so it can behaviour correctly.
> i think that this prevents the use of a single functional API.
>
> my thinking is along the lines of:
True enough..
>
> 1. introducing a new messaging style interface specifically for mail delivery
+1
> 2. introduce an efficient, simple, streaming POP3 backend API which
> can be adapted to MailRepository or other mailbox designs. performance
> for MailRepository would still suck but the OpenJPA (and potentially
> JCR) backends from IMAP could be used without heavy adaption or
> performance loss.
+1
> 3. add full support for flags to IMAP. use custom flags to support
> POP3 mailboxing correctly.
>
+1
> so, we'd lose a general interface but gain interoperability between
> the protocols.
>
> - robert
>
Sounds really good..
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jan 22, 2010 at 8:52 AM, Stefano Bagnara <ap...@bago.org> wrote:
> 2010/1/21 Robert Burrell Donkin <ro...@gmail.com>:
>> i think that using sieve to deliver IMAP mail is wrong. i think that
>> the script should set attributes on the mail (for example, set a
>> attribute for folder) and with independent delivery.
>
> 5 years ago I was proposing
> (http://markmail.org/message/xkcttgyqmfwpieew) to use a "destination"
> concept for moving mails around. I think we could use special email
> addresses (and maybe "forward paths", with reference to the "old"
> source routing stuff) so to still keep working with mail envelopes
> (even using a distributed email processor, as multiple james servers)
> or alternatively using urls. The fact is that "state" is not enough to
> deal with message routing so we need something more in the mailet api,
> and we can do this 2 ways: A. add routing methods, B. add some more
> expressive property than state.
sounds very interesting. could you write up the design more fully?
>>> But I think you are right, the current MailRepository stuff is really
>>> bad in terms of Performance.
>>
>> here's the issues which spring to mind:
>>
>> 1. the POP3 protocol stuff is sound enough but MailRepository insists
>> on instantiating heavy mail objects which kills performance for IMAP
>> (my server died several times a day before i ripped out this feature)
>
> The Mail object should not be so heavy as it tries to lazy load stuff.
> But I'm not against changing the way it works.
the lazy doesn't help in this case - IMAP just wants the meta-data or
the raw bytes.
>> 4. there are subtle semantic differences between the meanings of flags
>> in POP3, SMTP and IMAP
>
> Can you give more detail? I'm not sure I understand POP3 and SMTP "flags" ...
eg semantics of POP3 flagged delete is different from IMAP flagged
delete which is different from JavaMail. all subtle but really
annoying. IMAP has some stuff which are sort-of-flags which come from
the SMTP envelope. JavaMail's usage isn't compatible.
>> 5. there are subtle differences in rules between a POP3 INBOX and an
>> IMAP INBOX. not a problem to resolve but the code needs to understand
>> whether it's been used for IMAP or POP3 so it can behaviour correctly.
>> i think that this prevents the use of a single functional API.
>
> I need details on this too. POP3 does not have big requirements.
> It needs to be able to retrieve a list of message returning a "name"
> (persistent) and a size. Do you think this is hard to expose via an
> imap capable mail store? Or you are thinking of a mailbox api dealing
> with protocol stuff like "pop3 session", "deletes at the end of the
> session", "session sequence number for messages". At a glance we can
> deal with sessions at the protocol level using a very simple data
> access api.
i'm thinking about the very basic operations like getting a list of
emails in a mailbox, gaining streaming access to raw data and then
modifying POP3 flags so that mail deleted as far as POP3 is concerned.
>> my thinking is along the lines of:
>>
>> 1. introducing a new messaging style interface specifically for mail delivery
>
> Are you referring to the MailServer interface or an interface for the
> "Mail Envelope". With "Mail Envelope" (again something that I was
> discussing 5 years ago in the previous thread) the concept that we
> should separate the mime stream to a Message object and the smtp
> envelope to an envelope object and then reduce the mailrepository to a
> "message" repository and spool envelopes.
>
> So, at low level we could have an incoming message to be
> envelope+message.. smtp prepare the envelope object and stream the
> mime to a jcr content. Then puts the jcr url in the envelope and put
> the envelope in a jms queue. Then we move the envelope from queue to
> queue.
>
> Am I going off topic or is this what you had in mind with "new
> messaging style for mail delivery" ?
not so much off topic as further than's achievable in the time window
i have available
just thinking of switching to a different interface for
>> 2. introduce an efficient, simple, streaming POP3 backend API which
>> can be adapted to MailRepository or other mailbox designs. performance
>> for MailRepository would still suck but the OpenJPA (and potentially
>> JCR) backends from IMAP could be used without heavy adaption or
>> performance loss.
>
> IIRC I read multiple times that the current mailbox api is not great
> for imap: I don't know the imap stuff enough to make any statement on
> this but I'd like to understand if you think the goal is to improve it
> by making it more "imap oriented" or improve it by making it more
> "simple". I remember in past Joachim tried to explain me that imap
> reference emails with 3 types of identifiers and this make almost
> impossible to write a simple api for the message store: do you agree
> with joachim on this?
if you regard it as a store then yes
i believe other styles of API are possible. i think that a minimal
POP3 specific backend API could be adapted to both MailRepository and
IMAP.
IIRC POP3 just needs to know which emails are in the folder, stream
out raw emails and flag or mark mails in certain ways. all the session
management and protocol management foo would remain in the POP3
module.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Stefano Bagnara <ap...@bago.org>.
2010/1/21 Robert Burrell Donkin <ro...@gmail.com>:
> i think that using sieve to deliver IMAP mail is wrong. i think that
> the script should set attributes on the mail (for example, set a
> attribute for folder) and with independent delivery.
5 years ago I was proposing
(http://markmail.org/message/xkcttgyqmfwpieew) to use a "destination"
concept for moving mails around. I think we could use special email
addresses (and maybe "forward paths", with reference to the "old"
source routing stuff) so to still keep working with mail envelopes
(even using a distributed email processor, as multiple james servers)
or alternatively using urls. The fact is that "state" is not enough to
deal with message routing so we need something more in the mailet api,
and we can do this 2 ways: A. add routing methods, B. add some more
expressive property than state.
>> But I think you are right, the current MailRepository stuff is really
>> bad in terms of Performance.
>
> here's the issues which spring to mind:
>
> 1. the POP3 protocol stuff is sound enough but MailRepository insists
> on instantiating heavy mail objects which kills performance for IMAP
> (my server died several times a day before i ripped out this feature)
The Mail object should not be so heavy as it tries to lazy load stuff.
But I'm not against changing the way it works.
> 4. there are subtle semantic differences between the meanings of flags
> in POP3, SMTP and IMAP
Can you give more detail? I'm not sure I understand POP3 and SMTP "flags" ...
> 5. there are subtle differences in rules between a POP3 INBOX and an
> IMAP INBOX. not a problem to resolve but the code needs to understand
> whether it's been used for IMAP or POP3 so it can behaviour correctly.
> i think that this prevents the use of a single functional API.
I need details on this too. POP3 does not have big requirements.
It needs to be able to retrieve a list of message returning a "name"
(persistent) and a size. Do you think this is hard to expose via an
imap capable mail store? Or you are thinking of a mailbox api dealing
with protocol stuff like "pop3 session", "deletes at the end of the
session", "session sequence number for messages". At a glance we can
deal with sessions at the protocol level using a very simple data
access api.
> my thinking is along the lines of:
>
> 1. introducing a new messaging style interface specifically for mail delivery
Are you referring to the MailServer interface or an interface for the
"Mail Envelope". With "Mail Envelope" (again something that I was
discussing 5 years ago in the previous thread) the concept that we
should separate the mime stream to a Message object and the smtp
envelope to an envelope object and then reduce the mailrepository to a
"message" repository and spool envelopes.
So, at low level we could have an incoming message to be
envelope+message.. smtp prepare the envelope object and stream the
mime to a jcr content. Then puts the jcr url in the envelope and put
the envelope in a jms queue. Then we move the envelope from queue to
queue.
Am I going off topic or is this what you had in mind with "new
messaging style for mail delivery" ?
> 2. introduce an efficient, simple, streaming POP3 backend API which
> can be adapted to MailRepository or other mailbox designs. performance
> for MailRepository would still suck but the OpenJPA (and potentially
> JCR) backends from IMAP could be used without heavy adaption or
> performance loss.
IIRC I read multiple times that the current mailbox api is not great
for imap: I don't know the imap stuff enough to make any statement on
this but I'd like to understand if you think the goal is to improve it
by making it more "imap oriented" or improve it by making it more
"simple". I remember in past Joachim tried to explain me that imap
reference emails with 3 types of identifiers and this make almost
impossible to write a simple api for the message store: do you agree
with joachim on this?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Jan 21, 2010 at 4:27 PM, Norman Maurer <no...@apache.org> wrote:
> Sure, I would be very interested in discuss stuff.
cool
> I was just looking for a quick solution which give users who use James
> 2.3 not to much headach.
i think that should be possible
i think that using sieve to deliver IMAP mail is wrong. i think that
the script should set attributes on the mail (for example, set a
attribute for folder) and with independent delivery.
> But I think you are right, the current MailRepository stuff is really
> bad in terms of Performance.
here's the issues which spring to mind:
1. the POP3 protocol stuff is sound enough but MailRepository insists
on instantiating heavy mail objects which kills performance for IMAP
(my server died several times a day before i ripped out this feature)
2. the MailRepository allows actions which are incompatible with IMAP.
(IMAP relies on the actual mail being read only with meta data
including flags being read write.)
3. IMAP requires parsing supported by Mime4J which is incompatible
with javax mail
4. there are subtle semantic differences between the meanings of flags
in POP3, SMTP and IMAP
5. there are subtle differences in rules between a POP3 INBOX and an
IMAP INBOX. not a problem to resolve but the code needs to understand
whether it's been used for IMAP or POP3 so it can behaviour correctly.
i think that this prevents the use of a single functional API.
my thinking is along the lines of:
1. introducing a new messaging style interface specifically for mail delivery
2. introduce an efficient, simple, streaming POP3 backend API which
can be adapted to MailRepository or other mailbox designs. performance
for MailRepository would still suck but the OpenJPA (and potentially
JCR) backends from IMAP could be used without heavy adaption or
performance loss.
3. add full support for flags to IMAP. use custom flags to support
POP3 mailboxing correctly.
so, we'd lose a general interface but gain interoperability between
the protocols.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@apache.org>.
Sure, I would be very interested in discuss stuff.
I was just looking for a quick solution which give users who use James
2.3 not to much headach.
But I think you are right, the current MailRepository stuff is really
bad in terms of Performance.
Bye
Norman
2010/1/21, Robert Burrell Donkin <ro...@gmail.com>:
> On Wednesday, January 20, 2010, Norman Maurer <no...@apache.org> wrote:
>> Hi all,
>>
>> after I already brought this up some time in the past I thought a bit
>> more about MailRepository and MailboxManager. I'm still in favor to
>> just use one Repository for IMAP and POP3. I think its a no go to ship
>> different "storages" for the protocols. I know the requirement for
>> POP3 and IMAP are totally different but shouldn't it be possible to
>> write some adapter which will just expose the Mails via the
>> MailRepository interface but use an underlying MailboxManager to fetch
>> it ?
>>
>> So when an User would use IMAP he would get all he features of
>> MailboxManager, if he use POP3 he will just see the emails in the
>> Folder INBOX. Thats exactly how many unix mailserver do it. Like
>> Dovecot, Courier etc. So it can't be the worst idea =P
>>
>> Then we could mark the old implementations with "@deprecated" and
>> remove them later, or beeing more radical remove them now.
>> Mailmigration could just work with the RemoteManager and "movemails"
>> command.
>>
>> WDYT ?
>>
>> I think I remember Robert didn'T like the idea to much in the past..
>
> Sounds good but...
>
> ...there are issues with semantic incompatibilities between the
> protocols and performance issues with tha James repository layer.
>
> I spent almost a year fixing the problems the last time someone tried
> this. In the end the solution was very simple - scrap the adaption
> layer and rewrite the IMAP implementation from scratch.
>
> I've spent a couple of years thinking about this and think I
> understand why exchange took so long to get right. I now have some
> solutions which I think will work but start from the IMAP approach and
> will involve some clear re-thinking of some basic James concepts. The
> good news is that I think this will make exchange integration
> feasible.
>
> If there's interest in implementing, I should have time to outline
> what I learned.
>
> Opinions?
>
> Robert
>
>>
>> Bye,
>> Norman
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wednesday, January 20, 2010, Norman Maurer <no...@apache.org> wrote:
> Hi all,
>
> after I already brought this up some time in the past I thought a bit
> more about MailRepository and MailboxManager. I'm still in favor to
> just use one Repository for IMAP and POP3. I think its a no go to ship
> different "storages" for the protocols. I know the requirement for
> POP3 and IMAP are totally different but shouldn't it be possible to
> write some adapter which will just expose the Mails via the
> MailRepository interface but use an underlying MailboxManager to fetch
> it ?
>
> So when an User would use IMAP he would get all he features of
> MailboxManager, if he use POP3 he will just see the emails in the
> Folder INBOX. Thats exactly how many unix mailserver do it. Like
> Dovecot, Courier etc. So it can't be the worst idea =P
>
> Then we could mark the old implementations with "@deprecated" and
> remove them later, or beeing more radical remove them now.
> Mailmigration could just work with the RemoteManager and "movemails"
> command.
>
> WDYT ?
>
> I think I remember Robert didn'T like the idea to much in the past..
Sounds good but...
...there are issues with semantic incompatibilities between the
protocols and performance issues with tha James repository layer.
I spent almost a year fixing the problems the last time someone tried
this. In the end the solution was very simple - scrap the adaption
layer and rewrite the IMAP implementation from scratch.
I've spent a couple of years thinking about this and think I
understand why exchange took so long to get right. I now have some
solutions which I think will work but start from the IMAP approach and
will involve some clear re-thinking of some basic James concepts. The
good news is that I think this will make exchange integration
feasible.
If there's interest in implementing, I should have time to outline
what I learned.
Opinions?
Robert
>
> Bye,
> Norman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
AW: MailRepository and MailboxManager
Posted by Mario Zsilak <ma...@inew-cs.com>.
+1
However, one comment:
I would like to see that, if a POP3 user fetches his mails, he shall see all
of them (in all folders) - with the difference to IMAP that he doesn't see
his folder structure but only INBOX. At least it should be configurable.
----
What I can say from my experience in my company:
After 4 years of POP3, we finally convinced the company management to
upgrade our email package (hosted service) so that it includes IMAP. The
domain hoster told us that they can't migrate users / mails from POP3 to
IMAP and we had to do it manually ...
Let's do it better! OK, we may use RemoteManager and "movemails", but I
believe having a single Repository would be still better :)
Kind regards,
Mario
>-----Ursprüngliche Nachricht-----
>Von: norman.maurer@googlemail.com [mailto:norman.maurer@googlemail.com]
>Im Auftrag von Norman Maurer
>Gesendet: Mittwoch, 20. Januar 2010 12:38
>An: James Developers List
>Betreff: MailRepository and MailboxManager
>
>Hi all,
>
>after I already brought this up some time in the past I thought a bit
>more about MailRepository and MailboxManager. I'm still in favor to
>just use one Repository for IMAP and POP3. I think its a no go to ship
>different "storages" for the protocols. I know the requirement for
>POP3 and IMAP are totally different but shouldn't it be possible to
>write some adapter which will just expose the Mails via the
>MailRepository interface but use an underlying MailboxManager to fetch
>it ?
>
>So when an User would use IMAP he would get all he features of
>MailboxManager, if he use POP3 he will just see the emails in the
>Folder INBOX. Thats exactly how many unix mailserver do it. Like
>Dovecot, Courier etc. So it can't be the worst idea =P
>
>Then we could mark the old implementations with "@deprecated" and
>remove them later, or beeing more radical remove them now.
>Mailmigration could just work with the RemoteManager and "movemails"
>command.
>
>WDYT ?
>
>I think I remember Robert didn'T like the idea to much in the past..
>
>Bye,
>Norman
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Dhrubo <dh...@gmail.com>.
Agreed.
Can we add a migration util ;)
On Wed, Jan 20, 2010 at 6:53 PM, Norman Maurer <norman.maurer@googlemail.com
> wrote:
> When I talk about migration I'm talkin about users which already have
> emails in their inboxes (for example because they use james-2.3.x and
> want to upgrade). For new emails only the "new" repository should be
> used.
>
> Just to make it clear....
>
> Bye,
> Norman
>
>
> 2010/1/20 Dhrubo <dh...@gmail.com>:
> > I am also for single repository and 2 views
> > That way no migration or move is required.
> >
> > On Wed, Jan 20, 2010 at 6:25 PM, Mario Zsilak <mario.zsilak@inew-cs.com
> >wrote:
> >
> >> +1
> >>
> >> However, one comment:
> >> I would like to see that, if a POP3 user fetches his mails, he shall see
> >> all
> >> of them (in all folders) - with the difference to IMAP that he doesn't
> see
> >> his folder structure but only INBOX. At least it should be configurable.
> >>
> >> ----
> >>
> >> What I can say from my experience in my company:
> >> After 4 years of POP3, we finally convinced the company management to
> >> upgrade our email package (hosted service) so that it includes IMAP. The
> >> domain hoster told us that they can't migrate users / mails from POP3 to
> >> IMAP and we had to do it manually ...
> >>
> >> Let's do it better! OK, we may use RemoteManager and "movemails", but I
> >> believe having a single Repository would be still better :)
> >>
> >> Kind regards,
> >> Mario
> >>
> >> >-----Ursprüngliche Nachricht-----
> >> >Von: norman.maurer@googlemail.com [mailto:norman.maurer@googlemail.com
> ]
> >> >Im Auftrag von Norman Maurer
> >> >Gesendet: Mittwoch, 20. Januar 2010 12:38
> >> >An: James Developers List
> >> >Betreff: MailRepository and MailboxManager
> >> >
> >> >Hi all,
> >> >
> >> >after I already brought this up some time in the past I thought a bit
> >> >more about MailRepository and MailboxManager. I'm still in favor to
> >> >just use one Repository for IMAP and POP3. I think its a no go to ship
> >> >different "storages" for the protocols. I know the requirement for
> >> >POP3 and IMAP are totally different but shouldn't it be possible to
> >> >write some adapter which will just expose the Mails via the
> >> >MailRepository interface but use an underlying MailboxManager to fetch
> >> >it ?
> >> >
> >> >So when an User would use IMAP he would get all he features of
> >> >MailboxManager, if he use POP3 he will just see the emails in the
> >> >Folder INBOX. Thats exactly how many unix mailserver do it. Like
> >> >Dovecot, Courier etc. So it can't be the worst idea =P
> >> >
> >> >Then we could mark the old implementations with "@deprecated" and
> >> >remove them later, or beeing more radical remove them now.
> >> >Mailmigration could just work with the RemoteManager and "movemails"
> >> >command.
> >> >
> >> >WDYT ?
> >> >
> >> >I think I remember Robert didn'T like the idea to much in the past..
> >> >
> >> >Bye,
> >> >Norman
> >> >
> >> >---------------------------------------------------------------------
> >> >To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >> >For additional commands, e-mail: server-dev-help@james.apache.org
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >> For additional commands, e-mail: server-dev-help@james.apache.org
> >>
> >>
> >
> >
> > --
> > Thanks ... Dhrubo
> > My Book - http://www.apress.com/book/view/1430210095
> >
> > My Blog -
> > http://www.jtraining.com/blogs/blogger/dhrubo/
> >
> > LinkedIn - http://www.linkedin.com/in/dhrubo
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Thanks ... Dhrubo
My Book - http://www.apress.com/book/view/1430210095
My Blog -
http://www.jtraining.com/blogs/blogger/dhrubo/
LinkedIn - http://www.linkedin.com/in/dhrubo
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
When I talk about migration I'm talkin about users which already have
emails in their inboxes (for example because they use james-2.3.x and
want to upgrade). For new emails only the "new" repository should be
used.
Just to make it clear....
Bye,
Norman
2010/1/20 Dhrubo <dh...@gmail.com>:
> I am also for single repository and 2 views
> That way no migration or move is required.
>
> On Wed, Jan 20, 2010 at 6:25 PM, Mario Zsilak <ma...@inew-cs.com>wrote:
>
>> +1
>>
>> However, one comment:
>> I would like to see that, if a POP3 user fetches his mails, he shall see
>> all
>> of them (in all folders) - with the difference to IMAP that he doesn't see
>> his folder structure but only INBOX. At least it should be configurable.
>>
>> ----
>>
>> What I can say from my experience in my company:
>> After 4 years of POP3, we finally convinced the company management to
>> upgrade our email package (hosted service) so that it includes IMAP. The
>> domain hoster told us that they can't migrate users / mails from POP3 to
>> IMAP and we had to do it manually ...
>>
>> Let's do it better! OK, we may use RemoteManager and "movemails", but I
>> believe having a single Repository would be still better :)
>>
>> Kind regards,
>> Mario
>>
>> >-----Ursprüngliche Nachricht-----
>> >Von: norman.maurer@googlemail.com [mailto:norman.maurer@googlemail.com]
>> >Im Auftrag von Norman Maurer
>> >Gesendet: Mittwoch, 20. Januar 2010 12:38
>> >An: James Developers List
>> >Betreff: MailRepository and MailboxManager
>> >
>> >Hi all,
>> >
>> >after I already brought this up some time in the past I thought a bit
>> >more about MailRepository and MailboxManager. I'm still in favor to
>> >just use one Repository for IMAP and POP3. I think its a no go to ship
>> >different "storages" for the protocols. I know the requirement for
>> >POP3 and IMAP are totally different but shouldn't it be possible to
>> >write some adapter which will just expose the Mails via the
>> >MailRepository interface but use an underlying MailboxManager to fetch
>> >it ?
>> >
>> >So when an User would use IMAP he would get all he features of
>> >MailboxManager, if he use POP3 he will just see the emails in the
>> >Folder INBOX. Thats exactly how many unix mailserver do it. Like
>> >Dovecot, Courier etc. So it can't be the worst idea =P
>> >
>> >Then we could mark the old implementations with "@deprecated" and
>> >remove them later, or beeing more radical remove them now.
>> >Mailmigration could just work with the RemoteManager and "movemails"
>> >command.
>> >
>> >WDYT ?
>> >
>> >I think I remember Robert didn'T like the idea to much in the past..
>> >
>> >Bye,
>> >Norman
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> >For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
>
> --
> Thanks ... Dhrubo
> My Book - http://www.apress.com/book/view/1430210095
>
> My Blog -
> http://www.jtraining.com/blogs/blogger/dhrubo/
>
> LinkedIn - http://www.linkedin.com/in/dhrubo
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MailRepository and MailboxManager
Posted by Dhrubo <dh...@gmail.com>.
I am also for single repository and 2 views
That way no migration or move is required.
On Wed, Jan 20, 2010 at 6:25 PM, Mario Zsilak <ma...@inew-cs.com>wrote:
> +1
>
> However, one comment:
> I would like to see that, if a POP3 user fetches his mails, he shall see
> all
> of them (in all folders) - with the difference to IMAP that he doesn't see
> his folder structure but only INBOX. At least it should be configurable.
>
> ----
>
> What I can say from my experience in my company:
> After 4 years of POP3, we finally convinced the company management to
> upgrade our email package (hosted service) so that it includes IMAP. The
> domain hoster told us that they can't migrate users / mails from POP3 to
> IMAP and we had to do it manually ...
>
> Let's do it better! OK, we may use RemoteManager and "movemails", but I
> believe having a single Repository would be still better :)
>
> Kind regards,
> Mario
>
> >-----Ursprüngliche Nachricht-----
> >Von: norman.maurer@googlemail.com [mailto:norman.maurer@googlemail.com]
> >Im Auftrag von Norman Maurer
> >Gesendet: Mittwoch, 20. Januar 2010 12:38
> >An: James Developers List
> >Betreff: MailRepository and MailboxManager
> >
> >Hi all,
> >
> >after I already brought this up some time in the past I thought a bit
> >more about MailRepository and MailboxManager. I'm still in favor to
> >just use one Repository for IMAP and POP3. I think its a no go to ship
> >different "storages" for the protocols. I know the requirement for
> >POP3 and IMAP are totally different but shouldn't it be possible to
> >write some adapter which will just expose the Mails via the
> >MailRepository interface but use an underlying MailboxManager to fetch
> >it ?
> >
> >So when an User would use IMAP he would get all he features of
> >MailboxManager, if he use POP3 he will just see the emails in the
> >Folder INBOX. Thats exactly how many unix mailserver do it. Like
> >Dovecot, Courier etc. So it can't be the worst idea =P
> >
> >Then we could mark the old implementations with "@deprecated" and
> >remove them later, or beeing more radical remove them now.
> >Mailmigration could just work with the RemoteManager and "movemails"
> >command.
> >
> >WDYT ?
> >
> >I think I remember Robert didn'T like the idea to much in the past..
> >
> >Bye,
> >Norman
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
--
Thanks ... Dhrubo
My Book - http://www.apress.com/book/view/1430210095
My Blog -
http://www.jtraining.com/blogs/blogger/dhrubo/
LinkedIn - http://www.linkedin.com/in/dhrubo
Re: MailRepository and MailboxManager
Posted by Norman Maurer <no...@googlemail.com>.
Hi Mario,
seeing more then the emails in INBOX (POP3) does not seems like a good
idea to me.. Because in POP3 is only one "INBOX" we should only handle
this. Have to handle every email in every folder will be a pita
(IMHO).
Bye,
Norman
PS: I'm workin for an ISP, and if we would tell our users to not be
able to "migrate" the email they would prolly kill us ;)
2010/1/20 Mario Zsilak <ma...@inew-cs.com>:
> +1
>
> However, one comment:
> I would like to see that, if a POP3 user fetches his mails, he shall see all
> of them (in all folders) - with the difference to IMAP that he doesn't see
> his folder structure but only INBOX. At least it should be configurable.
>
> ----
>
> What I can say from my experience in my company:
> After 4 years of POP3, we finally convinced the company management to
> upgrade our email package (hosted service) so that it includes IMAP. The
> domain hoster told us that they can't migrate users / mails from POP3 to
> IMAP and we had to do it manually ...
>
> Let's do it better! OK, we may use RemoteManager and "movemails", but I
> believe having a single Repository would be still better :)
>
> Kind regards,
> Mario
>
>>-----Ursprüngliche Nachricht-----
>>Von: norman.maurer@googlemail.com [mailto:norman.maurer@googlemail.com]
>>Im Auftrag von Norman Maurer
>>Gesendet: Mittwoch, 20. Januar 2010 12:38
>>An: James Developers List
>>Betreff: MailRepository and MailboxManager
>>
>>Hi all,
>>
>>after I already brought this up some time in the past I thought a bit
>>more about MailRepository and MailboxManager. I'm still in favor to
>>just use one Repository for IMAP and POP3. I think its a no go to ship
>>different "storages" for the protocols. I know the requirement for
>>POP3 and IMAP are totally different but shouldn't it be possible to
>>write some adapter which will just expose the Mails via the
>>MailRepository interface but use an underlying MailboxManager to fetch
>>it ?
>>
>>So when an User would use IMAP he would get all he features of
>>MailboxManager, if he use POP3 he will just see the emails in the
>>Folder INBOX. Thats exactly how many unix mailserver do it. Like
>>Dovecot, Courier etc. So it can't be the worst idea =P
>>
>>Then we could mark the old implementations with "@deprecated" and
>>remove them later, or beeing more radical remove them now.
>>Mailmigration could just work with the RemoteManager and "movemails"
>>command.
>>
>>WDYT ?
>>
>>I think I remember Robert didn'T like the idea to much in the past..
>>
>>Bye,
>>Norman
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org