james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: [Discuss] MailRepository(Store) Naming
Date Fri, 31 Dec 2010 10:15:01 GMT
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.


On 29/12/2010 17:24, Norman Maurer wrote:
> Comments inside..
> 2010/12/28 Eric Charles<eric@apache.org>:
>> Hi,
>> See comments inside,
>> Eric
>> On 28/12/2010 14:24, Stefano Bagnara wrote:
>>> 2010/12/28 Eric Charles<eric@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

View raw message