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