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