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 Eric Charles <er...@apache.org> on 2010/12/28 10:15:47 UTC
[Discuss] MailRepository(Store) Naming
Hi,
MailRepository is ambiguous with Mailbox.
MailRepositoryStore used to list all available MailRepositories is not
as self-explanatory as we would want.
We can continue to used those names and bring documentation to explain
them such as in
http://james.apache.org/server/3/feature-persistence.html or we could
try to find new ones.
Some compound name with "Mail" inside (after all, it goes over mails)
would give something like "MailDepot" or "MailBin".
Do you think these are more distinctive from Mailbox?
Have you any other ideas?
Tks,
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [Discuss] MailRepository(Store) Naming
Posted by Eric Charles <er...@apache.org>.
Hi All,
Having the ability to store spam,... in a mailboxmanager-of-choice, or
in users's spam folder opens new doors.
When one of my user will ask me "where is my mail, it's even not in my
spam folder", I could always connect to the "all-spam" user via imap and
see if it's not there...
Anyway, we need to further think/talk about that in 2011 :)
Happy new Year to All, All the best, and I also wish to James Server a
happy 3.0 release.
Tks,
Eric
On 29/12/2010 17:24, Norman Maurer wrote:
> Comments inside..
>
> 2010/12/28 Eric Charles<er...@apache.org>:
>> Hi,
>> See comments inside,
>> Eric
>>
>> On 28/12/2010 14:24, Stefano Bagnara wrote:
>>> 2010/12/28 Eric Charles<er...@apache.org>:
>>>> 2 different persistences (mailbox, mailrepository) for mails sounds
>>>> curious,
>>>> but there are for different purposes (mailbox for users' mails,
>>>> mailrespository for the rest such as spam, virus).
>>>> Even if I was pro- for the merging of both, it seems that users' mailbox
>>>> should be much hacked to store "rest" mails (the spam, the virus,...).
>>> Why shouldn't we use mailbox for the spam/virus too?
>>>
>> Nothing against that imho.
>> I would simply want to be able to configure a different mailbox persistence
>> for virus than for the normal users's mail.
> Yeah it would make things easier.. I guess we could do some kind of
> magic here so you could select the right MailboxManager via some kind
> of url. Like :
>
> jcr://, jpa:// .....
>
>> I would also like to drive the spam (at least the mail with a spam-level
>> lower than a value) to a "Spam" folder of the user's, just like MS-Exchange
>> or Gmail does.
> I guess we could just do this in some Mailet which set some attribute
> and then the SieveMailet will take care of handling it..
>
>
>>>> For example, users having jpa mailbox would have an additional table to
>>>> persist the spam... What about maildir which is well defined and should
>>>> be
>>>> extended to support a "spam" dir.
>>> In my "view" spam should be destinated where the admin decide to
>>> destinate it. Some admins will prefer to have a spam folder in each
>>> mailbox, some other admins will prefer to have a single spam folder
>>> for the system (maybe a system mailbox?) others will want a spam
>>> folder for each user inside a spam mailbox. Doesn't this sound simpler
>>> than having different repositories?
>>>
>> This is what I was thinking at the begining.
>> Now I'm working with both mecanic, I don't find it too complicated.
>> But yes, adding for example nosql (hbase, casssandra or whatever) in merged
>> api would allow to do the job only once.
>>> I don't see big advantages in further promoting the use of "old"
>>> repositories: if we had GUIs or utilities to deal with them then we
>>> could leverage the tools, but there's nothing, so I would switch
>>> everything to mailbox.
>>> Eventually I would see 2 improvements:
>>> 1) Extract from mailbox a simpler interface for simply storing a
>>> message in a given folder (so this will make it simpler to create
>>> "write only" implementations for integrators)
>>> 2) Enhance current mailbox implementations to be "tunable" for
>>> write-intensive usage instead of read (so avoid creating indexes and
>>> other unused stuff in case of spam), or alternatively provide a simple
>>> write only mailbox implementation with low overhead.
>>>
>> I sometimes feel James Mailbox was designed with "IMAP" as goal.
>> This implies the current mailbox API is focused/optimized to support the
>> IMAP protocols/methods.
>> It's true that we could extend the application area and make Mailbox serve
>> as a more generic component, that would be embedded in any application
>> needing a "mailbox"
>> (For example, Patterns in Java Volume 3 defines a nice pattern called
>> ...'Mailbox' -
>> http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471267821.html)
>>
>> If we integrate one day mailbox and mailrepository, I would simply like to
>> have the ability to access different mailboxes types in the server.
>> 1.- The users mailbox (with spam to the user's "spam" folder) : a jpa one
>> for example.
>> 2.- Another mailbox for all the rest (virus, unknown users,...) : a file or
>> nosql based one for example.
>>
>> As adminstrator, I would also take care of the second one to for
>> analysis,... - so yes, the functions to offer (query,..) are important.
>>
>> To access to multiple mailboxmanagers, we would need a
>> MailboxManagerRegistry or something like that (the equivalent of the current
>> MailRepositoryStore).
> See above..
>
>>> Please note that while I know the old repository very well I'm not
>>> up-to-date with the mailbox stuff (I worked with it at the beginning
>>> but it's maybe 2 years ago.. and I don't remember), so maybe some/all
>>> of I said makes no sense, I'm just loud thinking.
>>>
>> I worked a bit with mailbox API, but i don't know it in depth, and was also
>> not part of the design phase.
>> Norman is probably the one to evaluate if this is judicious :) - this is
>> here where Norman is going to jump, I guess :)
>>>> So a // storage such as the current mailrepository is probably the less
>>>> intrusive option, even if we have to duplicate all the persistence
>>>> adapters
>>>> (database, file, jcr, nosql,...).
>>>>
>>>> Tks,
>>> Thanks to you!
>>>
>>> PS: Take my "messages" as simple ideas and suggestions (not
>>> requirements) as I'm not active on the code right now and I firmly
>>> believe that decisions belongs to people doing things :-)
>>>
>> We really need to open the discussion. So tks for your continuous support.
>>
>> PS : We must continue this discussion, but thinking loud, I feel we should
>> plan any action for 3.1 - 3.0 would remain with the existing MailRepository,
>> or whatever name we could give.
>>
>>> Stefano
>>>
>
> So I think I would also agree that using only one Mailbox API would
> give some benefits.. Maybe we should just put an "API" as wrapper
> around of the Mailbox API to simplify things.. Like make it an one
> method call to append a mail / delete a mail etc..
>
> WDYT..
>
> 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: [Discuss] MailRepository(Store) Naming
Posted by Norman Maurer <no...@apache.org>.
Comments inside..
2010/12/28 Eric Charles <er...@apache.org>:
> Hi,
> See comments inside,
> Eric
>
> On 28/12/2010 14:24, Stefano Bagnara wrote:
>>
>> 2010/12/28 Eric Charles<er...@apache.org>:
>>>
>>> 2 different persistences (mailbox, mailrepository) for mails sounds
>>> curious,
>>> but there are for different purposes (mailbox for users' mails,
>>> mailrespository for the rest such as spam, virus).
>>> Even if I was pro- for the merging of both, it seems that users' mailbox
>>> should be much hacked to store "rest" mails (the spam, the virus,...).
>>
>> Why shouldn't we use mailbox for the spam/virus too?
>>
>
> Nothing against that imho.
> I would simply want to be able to configure a different mailbox persistence
> for virus than for the normal users's mail.
Yeah it would make things easier.. I guess we could do some kind of
magic here so you could select the right MailboxManager via some kind
of url. Like :
jcr://, jpa:// .....
> I would also like to drive the spam (at least the mail with a spam-level
> lower than a value) to a "Spam" folder of the user's, just like MS-Exchange
> or Gmail does.
I guess we could just do this in some Mailet which set some attribute
and then the SieveMailet will take care of handling it..
>
>>> For example, users having jpa mailbox would have an additional table to
>>> persist the spam... What about maildir which is well defined and should
>>> be
>>> extended to support a "spam" dir.
>>
>> In my "view" spam should be destinated where the admin decide to
>> destinate it. Some admins will prefer to have a spam folder in each
>> mailbox, some other admins will prefer to have a single spam folder
>> for the system (maybe a system mailbox?) others will want a spam
>> folder for each user inside a spam mailbox. Doesn't this sound simpler
>> than having different repositories?
>>
> This is what I was thinking at the begining.
> Now I'm working with both mecanic, I don't find it too complicated.
> But yes, adding for example nosql (hbase, casssandra or whatever) in merged
> api would allow to do the job only once.
>>
>> I don't see big advantages in further promoting the use of "old"
>> repositories: if we had GUIs or utilities to deal with them then we
>> could leverage the tools, but there's nothing, so I would switch
>> everything to mailbox.
>> Eventually I would see 2 improvements:
>> 1) Extract from mailbox a simpler interface for simply storing a
>> message in a given folder (so this will make it simpler to create
>> "write only" implementations for integrators)
>> 2) Enhance current mailbox implementations to be "tunable" for
>> write-intensive usage instead of read (so avoid creating indexes and
>> other unused stuff in case of spam), or alternatively provide a simple
>> write only mailbox implementation with low overhead.
>>
> I sometimes feel James Mailbox was designed with "IMAP" as goal.
> This implies the current mailbox API is focused/optimized to support the
> IMAP protocols/methods.
> It's true that we could extend the application area and make Mailbox serve
> as a more generic component, that would be embedded in any application
> needing a "mailbox"
> (For example, Patterns in Java Volume 3 defines a nice pattern called
> ...'Mailbox' -
> http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471267821.html)
>
> If we integrate one day mailbox and mailrepository, I would simply like to
> have the ability to access different mailboxes types in the server.
> 1.- The users mailbox (with spam to the user's "spam" folder) : a jpa one
> for example.
> 2.- Another mailbox for all the rest (virus, unknown users,...) : a file or
> nosql based one for example.
>
> As adminstrator, I would also take care of the second one to for
> analysis,... - so yes, the functions to offer (query,..) are important.
>
> To access to multiple mailboxmanagers, we would need a
> MailboxManagerRegistry or something like that (the equivalent of the current
> MailRepositoryStore).
See above..
>
>> Please note that while I know the old repository very well I'm not
>> up-to-date with the mailbox stuff (I worked with it at the beginning
>> but it's maybe 2 years ago.. and I don't remember), so maybe some/all
>> of I said makes no sense, I'm just loud thinking.
>>
> I worked a bit with mailbox API, but i don't know it in depth, and was also
> not part of the design phase.
> Norman is probably the one to evaluate if this is judicious :) - this is
> here where Norman is going to jump, I guess :)
>>>
>>> So a // storage such as the current mailrepository is probably the less
>>> intrusive option, even if we have to duplicate all the persistence
>>> adapters
>>> (database, file, jcr, nosql,...).
>>>
>>> Tks,
>>
>> Thanks to you!
>>
>> PS: Take my "messages" as simple ideas and suggestions (not
>> requirements) as I'm not active on the code right now and I firmly
>> believe that decisions belongs to people doing things :-)
>>
>
> We really need to open the discussion. So tks for your continuous support.
>
> PS : We must continue this discussion, but thinking loud, I feel we should
> plan any action for 3.1 - 3.0 would remain with the existing MailRepository,
> or whatever name we could give.
>
>> Stefano
>>
So I think I would also agree that using only one Mailbox API would
give some benefits.. Maybe we should just put an "API" as wrapper
around of the Mailbox API to simplify things.. Like make it an one
method call to append a mail / delete a mail etc..
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: [Discuss] MailRepository(Store) Naming
Posted by Eric Charles <er...@apache.org>.
Hi,
See comments inside,
Eric
On 28/12/2010 14:24, Stefano Bagnara wrote:
> 2010/12/28 Eric Charles<er...@apache.org>:
>> 2 different persistences (mailbox, mailrepository) for mails sounds curious,
>> but there are for different purposes (mailbox for users' mails,
>> mailrespository for the rest such as spam, virus).
>> Even if I was pro- for the merging of both, it seems that users' mailbox
>> should be much hacked to store "rest" mails (the spam, the virus,...).
> Why shouldn't we use mailbox for the spam/virus too?
>
Nothing against that imho.
I would simply want to be able to configure a different mailbox
persistence for virus than for the normal users's mail.
I would also like to drive the spam (at least the mail with a spam-level
lower than a value) to a "Spam" folder of the user's, just like
MS-Exchange or Gmail does.
>> For example, users having jpa mailbox would have an additional table to
>> persist the spam... What about maildir which is well defined and should be
>> extended to support a "spam" dir.
> In my "view" spam should be destinated where the admin decide to
> destinate it. Some admins will prefer to have a spam folder in each
> mailbox, some other admins will prefer to have a single spam folder
> for the system (maybe a system mailbox?) others will want a spam
> folder for each user inside a spam mailbox. Doesn't this sound simpler
> than having different repositories?
>
This is what I was thinking at the begining.
Now I'm working with both mecanic, I don't find it too complicated.
But yes, adding for example nosql (hbase, casssandra or whatever) in
merged api would allow to do the job only once.
> I don't see big advantages in further promoting the use of "old"
> repositories: if we had GUIs or utilities to deal with them then we
> could leverage the tools, but there's nothing, so I would switch
> everything to mailbox.
> Eventually I would see 2 improvements:
> 1) Extract from mailbox a simpler interface for simply storing a
> message in a given folder (so this will make it simpler to create
> "write only" implementations for integrators)
> 2) Enhance current mailbox implementations to be "tunable" for
> write-intensive usage instead of read (so avoid creating indexes and
> other unused stuff in case of spam), or alternatively provide a simple
> write only mailbox implementation with low overhead.
>
I sometimes feel James Mailbox was designed with "IMAP" as goal.
This implies the current mailbox API is focused/optimized to support the
IMAP protocols/methods.
It's true that we could extend the application area and make Mailbox
serve as a more generic component, that would be embedded in any
application needing a "mailbox"
(For example, Patterns in Java Volume 3 defines a nice pattern called
...'Mailbox' -
http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471267821.html)
If we integrate one day mailbox and mailrepository, I would simply like
to have the ability to access different mailboxes types in the server.
1.- The users mailbox (with spam to the user's "spam" folder) : a jpa
one for example.
2.- Another mailbox for all the rest (virus, unknown users,...) : a file
or nosql based one for example.
As adminstrator, I would also take care of the second one to for
analysis,... - so yes, the functions to offer (query,..) are important.
To access to multiple mailboxmanagers, we would need a
MailboxManagerRegistry or something like that (the equivalent of the
current MailRepositoryStore).
> Please note that while I know the old repository very well I'm not
> up-to-date with the mailbox stuff (I worked with it at the beginning
> but it's maybe 2 years ago.. and I don't remember), so maybe some/all
> of I said makes no sense, I'm just loud thinking.
>
I worked a bit with mailbox API, but i don't know it in depth, and was
also not part of the design phase.
Norman is probably the one to evaluate if this is judicious :) - this is
here where Norman is going to jump, I guess :)
>> So a // storage such as the current mailrepository is probably the less
>> intrusive option, even if we have to duplicate all the persistence adapters
>> (database, file, jcr, nosql,...).
>>
>> Tks,
> Thanks to you!
>
> PS: Take my "messages" as simple ideas and suggestions (not
> requirements) as I'm not active on the code right now and I firmly
> believe that decisions belongs to people doing things :-)
>
We really need to open the discussion. So tks for your continuous support.
PS : We must continue this discussion, but thinking loud, I feel we
should plan any action for 3.1 - 3.0 would remain with the existing
MailRepository, or whatever name we could give.
> Stefano
>
> ---------------------------------------------------------------------
> 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: [Discuss] MailRepository(Store) Naming
Posted by Stefano Bagnara <ap...@bago.org>.
2010/12/28 Eric Charles <er...@apache.org>:
> 2 different persistences (mailbox, mailrepository) for mails sounds curious,
> but there are for different purposes (mailbox for users' mails,
> mailrespository for the rest such as spam, virus).
> Even if I was pro- for the merging of both, it seems that users' mailbox
> should be much hacked to store "rest" mails (the spam, the virus,...).
Why shouldn't we use mailbox for the spam/virus too?
> For example, users having jpa mailbox would have an additional table to
> persist the spam... What about maildir which is well defined and should be
> extended to support a "spam" dir.
In my "view" spam should be destinated where the admin decide to
destinate it. Some admins will prefer to have a spam folder in each
mailbox, some other admins will prefer to have a single spam folder
for the system (maybe a system mailbox?) others will want a spam
folder for each user inside a spam mailbox. Doesn't this sound simpler
than having different repositories?
I don't see big advantages in further promoting the use of "old"
repositories: if we had GUIs or utilities to deal with them then we
could leverage the tools, but there's nothing, so I would switch
everything to mailbox.
Eventually I would see 2 improvements:
1) Extract from mailbox a simpler interface for simply storing a
message in a given folder (so this will make it simpler to create
"write only" implementations for integrators)
2) Enhance current mailbox implementations to be "tunable" for
write-intensive usage instead of read (so avoid creating indexes and
other unused stuff in case of spam), or alternatively provide a simple
write only mailbox implementation with low overhead.
Please note that while I know the old repository very well I'm not
up-to-date with the mailbox stuff (I worked with it at the beginning
but it's maybe 2 years ago.. and I don't remember), so maybe some/all
of I said makes no sense, I'm just loud thinking.
> So a // storage such as the current mailrepository is probably the less
> intrusive option, even if we have to duplicate all the persistence adapters
> (database, file, jcr, nosql,...).
>
> Tks,
Thanks to you!
PS: Take my "messages" as simple ideas and suggestions (not
requirements) as I'm not active on the code right now and I firmly
believe that decisions belongs to people doing things :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [Discuss] MailRepository(Store) Naming
Posted by Eric Charles <er...@apache.org>.
2 different persistences (mailbox, mailrepository) for mails sounds
curious, but there are for different purposes (mailbox for users' mails,
mailrespository for the rest such as spam, virus).
Even if I was pro- for the merging of both, it seems that users' mailbox
should be much hacked to store "rest" mails (the spam, the virus,...).
For example, users having jpa mailbox would have an additional table to
persist the spam... What about maildir which is well defined and should
be extended to support a "spam" dir.
So a // storage such as the current mailrepository is probably the less
intrusive option, even if we have to duplicate all the persistence
adapters (database, file, jcr, nosql,...).
Tks,
Eric
On 28/12/2010 11:16, Norman Maurer wrote:
> Well I think it still can be used to store Mail objects from Mailets.
> Or you think we would be better of to just use the "Mailbox API" there
> too ? At the moment the Mailbox API only supports users mailboxes so
> its not really a good fit as far as I can tell..
>
> Bye,
> Norman
>
> 2010/12/28 Stefano Bagnara<ap...@bago.org>:
>> So the Repository stuff should not be used at all in James 3.
>> Maybe we should leave it there only for people having to migrate data.
>>
>> I see we probably need replacement for ToRepository with a couple of mailets:
>> 1) A mailet that write the message to a specific folder of a specific mailbox.
>> 2) A mailet that stores the mimemessage as a plain mime file in a folder.
>>
>> Stefano
>>
>> 2010/12/28 Norman Maurer<no...@apache.org>:
>>> Hi there,
>>>
>>> Mailbox store kind of simple streams with some metadata (its the
>>> mailbox project stuff). MailRepository is the old one we used in james
>>> 2.3 for INBOX and as basis for the SpoolRepository. In the current
>>> james its only used for storing Mails via the ToRepository Mailet..
>>>
>>> Bye,
>>> Norman
>>>
>>> 2010/12/28 Stefano Bagnara<ap...@bago.org>:
>>>> What do we store in each one?
>>>>
>>>> Does Mailbox contains Mail objects, javamail MimeMessage, simple streams?
>>>> Is MailRepository the "old one" containing Mail objects?
>>>>
>>>> What about renaming MailRepository to EnvelopeRepository and the store
>>>> to EnvelopeRepositoryRegistry?
>>>>
>>>> Stefano
>>>>
>>>> 2010/12/28 Eric Charles<er...@apache.org>:
>>>>> Hi,
>>>>>
>>>>> MailRepository is ambiguous with Mailbox.
>>>>> MailRepositoryStore used to list all available MailRepositories is not as
>>>>> self-explanatory as we would want.
>>>>>
>>>>> We can continue to used those names and bring documentation to explain them
>>>>> such as in http://james.apache.org/server/3/feature-persistence.html or we
>>>>> could try to find new ones.
>>>>>
>>>>> Some compound name with "Mail" inside (after all, it goes over mails) would
>>>>> give something like "MailDepot" or "MailBin".
>>>>>
>>>>> Do you think these are more distinctive from Mailbox?
>>>>> Have you any other ideas?
>>>>>
>>>>> Tks,
>>>>>
>>>>> Eric
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
> ---------------------------------------------------------------------
> 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: [Discuss] MailRepository(Store) Naming
Posted by Norman Maurer <no...@apache.org>.
Well I think it still can be used to store Mail objects from Mailets.
Or you think we would be better of to just use the "Mailbox API" there
too ? At the moment the Mailbox API only supports users mailboxes so
its not really a good fit as far as I can tell..
Bye,
Norman
2010/12/28 Stefano Bagnara <ap...@bago.org>:
> So the Repository stuff should not be used at all in James 3.
> Maybe we should leave it there only for people having to migrate data.
>
> I see we probably need replacement for ToRepository with a couple of mailets:
> 1) A mailet that write the message to a specific folder of a specific mailbox.
> 2) A mailet that stores the mimemessage as a plain mime file in a folder.
>
> Stefano
>
> 2010/12/28 Norman Maurer <no...@apache.org>:
>> Hi there,
>>
>> Mailbox store kind of simple streams with some metadata (its the
>> mailbox project stuff). MailRepository is the old one we used in james
>> 2.3 for INBOX and as basis for the SpoolRepository. In the current
>> james its only used for storing Mails via the ToRepository Mailet..
>>
>> Bye,
>> Norman
>>
>> 2010/12/28 Stefano Bagnara <ap...@bago.org>:
>>> What do we store in each one?
>>>
>>> Does Mailbox contains Mail objects, javamail MimeMessage, simple streams?
>>> Is MailRepository the "old one" containing Mail objects?
>>>
>>> What about renaming MailRepository to EnvelopeRepository and the store
>>> to EnvelopeRepositoryRegistry?
>>>
>>> Stefano
>>>
>>> 2010/12/28 Eric Charles <er...@apache.org>:
>>>> Hi,
>>>>
>>>> MailRepository is ambiguous with Mailbox.
>>>> MailRepositoryStore used to list all available MailRepositories is not as
>>>> self-explanatory as we would want.
>>>>
>>>> We can continue to used those names and bring documentation to explain them
>>>> such as in http://james.apache.org/server/3/feature-persistence.html or we
>>>> could try to find new ones.
>>>>
>>>> Some compound name with "Mail" inside (after all, it goes over mails) would
>>>> give something like "MailDepot" or "MailBin".
>>>>
>>>> Do you think these are more distinctive from Mailbox?
>>>> Have you any other ideas?
>>>>
>>>> Tks,
>>>>
>>>> Eric
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [Discuss] MailRepository(Store) Naming
Posted by Stefano Bagnara <ap...@bago.org>.
So the Repository stuff should not be used at all in James 3.
Maybe we should leave it there only for people having to migrate data.
I see we probably need replacement for ToRepository with a couple of mailets:
1) A mailet that write the message to a specific folder of a specific mailbox.
2) A mailet that stores the mimemessage as a plain mime file in a folder.
Stefano
2010/12/28 Norman Maurer <no...@apache.org>:
> Hi there,
>
> Mailbox store kind of simple streams with some metadata (its the
> mailbox project stuff). MailRepository is the old one we used in james
> 2.3 for INBOX and as basis for the SpoolRepository. In the current
> james its only used for storing Mails via the ToRepository Mailet..
>
> Bye,
> Norman
>
> 2010/12/28 Stefano Bagnara <ap...@bago.org>:
>> What do we store in each one?
>>
>> Does Mailbox contains Mail objects, javamail MimeMessage, simple streams?
>> Is MailRepository the "old one" containing Mail objects?
>>
>> What about renaming MailRepository to EnvelopeRepository and the store
>> to EnvelopeRepositoryRegistry?
>>
>> Stefano
>>
>> 2010/12/28 Eric Charles <er...@apache.org>:
>>> Hi,
>>>
>>> MailRepository is ambiguous with Mailbox.
>>> MailRepositoryStore used to list all available MailRepositories is not as
>>> self-explanatory as we would want.
>>>
>>> We can continue to used those names and bring documentation to explain them
>>> such as in http://james.apache.org/server/3/feature-persistence.html or we
>>> could try to find new ones.
>>>
>>> Some compound name with "Mail" inside (after all, it goes over mails) would
>>> give something like "MailDepot" or "MailBin".
>>>
>>> Do you think these are more distinctive from Mailbox?
>>> Have you any other ideas?
>>>
>>> Tks,
>>>
>>> Eric
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: [Discuss] MailRepository(Store) Naming
Posted by Eric Charles <er...@apache.org>.
Hi Stefano,
Yes, Mailbox contains the users' mails (just like he sees it in its mail
client, classed by "folder").
Depending on the configuration, the mails are stored in files (maildir:
1 file by mail), database (jpa: headers and body splitted, body as a
blob),...
MailRepository used the james 2.3 technology (file, jdbc,...) to persist
all other mails (non mailbox)
MailRepositoryStore is the list of available MailRepositories in the server.
Naming criteria should be:
- Be distinctive from Mailbox (user/developer must not confuse both,
which is the case now)
- Indicate that it is not for end-user mails but for all the rest (spam,
virussed, undelivered, deadletter,... mails).
- Not break the ToRepository mailet API (if api says ToRepository..., it
should go to a Repository)
- Be nice to read and to code :)
I like the idea of "Registry" as a replacement for "Store". It
represents well some stuff have been registered and are available for use.
I've got mixed feeling on EnvelopeRepository.
On one side, it shows that it contains envelope (closed mails) so "not
to be read".
On the other side, it could let think that it contains the technical
envelope (headers,...) of the end-user mail, so still confusing with the
Mailbox's mails.
Same comment for LetterRepository (and its LetterRepositoryRegistry)...
Tks,
Eric
On 28/12/2010 10:56, Norman Maurer wrote:
> Hi there,
>
> Mailbox store kind of simple streams with some metadata (its the
> mailbox project stuff). MailRepository is the old one we used in james
> 2.3 for INBOX and as basis for the SpoolRepository. In the current
> james its only used for storing Mails via the ToRepository Mailet..
>
> Bye,
> Norman
>
> 2010/12/28 Stefano Bagnara<ap...@bago.org>:
>> What do we store in each one?
>>
>> Does Mailbox contains Mail objects, javamail MimeMessage, simple streams?
>> Is MailRepository the "old one" containing Mail objects?
>>
>> What about renaming MailRepository to EnvelopeRepository and the store
>> to EnvelopeRepositoryRegistry?
>>
>> Stefano
>>
>> 2010/12/28 Eric Charles<er...@apache.org>:
>>> Hi,
>>>
>>> MailRepository is ambiguous with Mailbox.
>>> MailRepositoryStore used to list all available MailRepositories is not as
>>> self-explanatory as we would want.
>>>
>>> We can continue to used those names and bring documentation to explain them
>>> such as in http://james.apache.org/server/3/feature-persistence.html or we
>>> could try to find new ones.
>>>
>>> Some compound name with "Mail" inside (after all, it goes over mails) would
>>> give something like "MailDepot" or "MailBin".
>>>
>>> Do you think these are more distinctive from Mailbox?
>>> Have you any other ideas?
>>>
>>> Tks,
>>>
>>> Eric
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: [Discuss] MailRepository(Store) Naming
Posted by Norman Maurer <no...@apache.org>.
Hi there,
Mailbox store kind of simple streams with some metadata (its the
mailbox project stuff). MailRepository is the old one we used in james
2.3 for INBOX and as basis for the SpoolRepository. In the current
james its only used for storing Mails via the ToRepository Mailet..
Bye,
Norman
2010/12/28 Stefano Bagnara <ap...@bago.org>:
> What do we store in each one?
>
> Does Mailbox contains Mail objects, javamail MimeMessage, simple streams?
> Is MailRepository the "old one" containing Mail objects?
>
> What about renaming MailRepository to EnvelopeRepository and the store
> to EnvelopeRepositoryRegistry?
>
> Stefano
>
> 2010/12/28 Eric Charles <er...@apache.org>:
>> Hi,
>>
>> MailRepository is ambiguous with Mailbox.
>> MailRepositoryStore used to list all available MailRepositories is not as
>> self-explanatory as we would want.
>>
>> We can continue to used those names and bring documentation to explain them
>> such as in http://james.apache.org/server/3/feature-persistence.html or we
>> could try to find new ones.
>>
>> Some compound name with "Mail" inside (after all, it goes over mails) would
>> give something like "MailDepot" or "MailBin".
>>
>> Do you think these are more distinctive from Mailbox?
>> Have you any other ideas?
>>
>> Tks,
>>
>> Eric
>>
>>
>> ---------------------------------------------------------------------
>> 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: [Discuss] MailRepository(Store) Naming
Posted by Stefano Bagnara <ap...@bago.org>.
What do we store in each one?
Does Mailbox contains Mail objects, javamail MimeMessage, simple streams?
Is MailRepository the "old one" containing Mail objects?
What about renaming MailRepository to EnvelopeRepository and the store
to EnvelopeRepositoryRegistry?
Stefano
2010/12/28 Eric Charles <er...@apache.org>:
> Hi,
>
> MailRepository is ambiguous with Mailbox.
> MailRepositoryStore used to list all available MailRepositories is not as
> self-explanatory as we would want.
>
> We can continue to used those names and bring documentation to explain them
> such as in http://james.apache.org/server/3/feature-persistence.html or we
> could try to find new ones.
>
> Some compound name with "Mail" inside (after all, it goes over mails) would
> give something like "MailDepot" or "MailBin".
>
> Do you think these are more distinctive from Mailbox?
> Have you any other ideas?
>
> Tks,
>
> Eric
>
>
> ---------------------------------------------------------------------
> 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