Joachim Draeger wrote:
As a sidenote I think that we can safely include your
javamailstore-mailrepository work in trunk, but this has not much to
do with IMAP.
Yes I think so. While working on MessageRepository performance and
compatibility of javamailstore-mailrepository could get better by
lowering the requirements. (no user generated key).
Yes, that was one of the few things I was thinking to include.
I think that we should do this for both Spool and Message repositories:
keys have to be generated by the repositories: instert and update have
to be 2 different operations (and not based on the existence of the same
key, as it won't be possible anymore).
I started reviewing what you publshed here:
http://www.joachim-draeger.de/JamesImap/drafts.html
I think that even the single M1 step is too much stuff and we should
start with a much simpler set of interfaces.
In the last step I tried to breakup the interfaces in more parts, so
only a subset is needed.
But it won't work below MailboxRepository and ImapMailbox.
Is EventTriggerMailbox so important for basic proof of concept usage?
Is the whole "column selection" stuff (MessageResult) / messageSetTypes
a need for the basic repository interface?
I thought we could start with a basic support for result and maybe a
single messageSetType and eventually introduce the
selection/capabilities methods later so we don't start being binded to a
complex api at an early stage. Btw I know I looked at this code much
less than you and I'm really happy to see you're still working on it and
doing big progresses, so I think I should better wait a little more and
study your code before to ask why we need all that stuff.
I'm quite curious what you think about GeneralMessageSet and MessageResult.
I started a JDBC prototype and found it quite handy.
Well, the only thing from M1 that could be postponed is the Javamail
proof-of-concept.
I don't like GeneralMessageSet becase:
1) Why do we need 3 types of keys (uid/msn/key) in a generic message
repository?
2) Imo the name is misleading: It is not a messageSet but a SearchCriteria.
About MessageResult:
1) I think we should not reference Mail objects here, but only
MimeMessage objects (or even simple streams)
2) Why Key/Flags/Msn/Uid/InternalDate are present in this interface and,
as an example, the From or the Subject is not there? Is this related to
what the IMAP protocol needs?
3) It seems TOO much IMAP oriented to not have Imap in the name: I don't
think that (as an example) an NNTPMessageRepository would need
Msn/Uid/Key/Flags and maybe it would need something else (I wrote part
of NNTP daemon almost 10 years ago, but I don't remember anything :-( )
That said I'm not against making an IMAP specific repository and I
always said that we should have a clear goal (Imap support) and create a
repository based on the specific needs of Imap (or better the specific
uses the most common Imap clients make of the Imap server).
I still don't know what are the most common operations requested by an
Imap client: check new messages, mark as read, move, send messages,
sort, archive.. I never used imap very much so I don't know what it
really happens on the wire.
Either way I don't want to have IMAP specific stuff in the main
messagerepository interface and what you called Mailbox already has too
much stuff that is not needed by POP3.
POP3 needs:
- read a full message
- read N lines or the full header
- get the list of message keys and their sizes
- get a count of the total number of messages (and possibly their total
size)
- delete a message
Our repository currenlty is not so good for the "key size" list and for
the "total size" result.
Is there a similar "analysis" done for Imap? I know that the imap
protocol itself provides a lot of features, but I also wonder if the
imap clients uses all of IMAP commands in all the ways or if we have a
subset of used "commands with specific parameters".
I thought that the following steps could be included in the roadmap as
a starting point.
1) the MessageRepository (Mailbox) interface: this would replace the
current MailRepository but would not include the Mail object but
simply the Message object/stream (and eventually some more
attributes). The default messageRepository generates its own key and
provides few methods to store/retrieve/delete messages (maybe we could
add "move" later). Imho the basing MessageRepository should be really,
really easy!
Well, but you can't avoid the uid-stuff in any way.
Right. the key would be definitely generated by the
MessageRepository.insert() method.
And you need something to manage hierarchy.
But I think it would be really a good step to introduce a
MessageRepository now, to be able to deprecate MailRepository for user
mailboxes in the future.
MessageRepository should be treated through a session. For many storage
backends you need to do some caching or keep resources open.
Because the GC is not an option the MessageRepository should be told,
when it is no longer needed, so it can free resources.
You're right. I evaluated this things when I used JMS the first time: if
we want to be able to introduce transactions or to have any control we
have to introduce a session.
Even for pop3 a permanent key is needed, which could be hash-sum. But
that key should only be provided on demand. Who needs it when storing a
message in a smtp -session?
2) some sort of named repository mapper: this has been discussed in
past and is described here:
http://wiki.apache.org/james/JamesV3/Plans (Message repository
directory structure).
But it would be still needed to introduce a Manager class to
create/rename/delete and access those repositories.
The advantage of logical mailbox names is, that the mapping
possibilities can be extended in the future.
At first every user mailbox like #users.joachim.INBOX ( I prefer the
common IMAP notation) is mapped to one sort of repository.
In the future there may be even user attributes from the User object,
that define where this mailbox exists.
Right. The Manager would be the "Store". Now we only ask it for named
repositories and it returns File based or JDBC based repositories. We
could add to it the management commands
(create/move/delete/link-or-mount repository) and make it possible for
few returned repositories to use this commands to alter themselves.
This deserve much more analysis, that I will delay to the moment I will
be able to work on it and study the related code, but I think this would
be a good step.
The accessing services like smtp/pop/imap/nntp servers or mailets don't
have to care about it. They only have to care if the capabilities are
sufficient for the purpose.
Right.
For example: it's a common practice to access news through imap by
#news.comp.os.linux etc.
It's even imaginable to access #spool.* through IMAP for administration.
SpoolRepository and MessageRepositories will not be related any more. I
don't think that we'll ever need/want to write a
SpoolRepositoryAsMessageRepositoryWrapper.
Once this will be in the repository we will discuss what is the
minimal set of features you included in ImapMailboxRepository to be
able to include the imap code in trunk so that I can send a message
via SMTP and retrieve via IMAP. I think that the goal is to be able to
commit the imap code to trunk. As soon as the code will be on trunk it
will be easier to discuss following steps and to involve further people.
To have something more concrete I just started to implement a Apache
Torque/JDBC based backend. It already helped me to find out a few weak
points of the design.
Great news!
Good choice with Torque as it is license compatible with James!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
