Comments inside.. 2010/12/28 Eric Charles <[email protected]>: > Hi, > See comments inside, > Eric > > On 28/12/2010 14:24, Stefano Bagnara wrote: >> >> 2010/12/28 Eric Charles<[email protected]>: >>> >>> 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: [email protected] For additional commands, e-mail: [email protected]
