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?

> 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to