Joachim Draeger schrieb:
Hi Bernd,
Am Dienstag, den 03.10.2006, 13:34 +0200 schrieb Bernd Fondermann:
as far as I understand, we need to alter the way we see/handle
repositories for getting IMAP to work before doing IMAP itself.
Well, James IMAP code is running. It was runnable all the time sleeping
in the archives. The only problem was the missing backend. Development
and testing is hard with an in-memory-only solution.
Wow, then we really miss something.. Thx for diggin
while I see there has been some discussion about this mixed in here,
what is the current architectural target for this?
currently, I am having problems to determine our roadmap concerning
this. (did I miss something?)
It's like every time at the James project. A proposal is done, some
discussion raises up. If a "religious" architecture topic is hit like
"too much protocol dependent" there is a lot of discussion for a short
time.
The problem is discussion hibernates without a result.
I must agree even if i not like the statement. We need to find better ways..
from my view, it would be important for an user's mail repository to
be accessible through POP3 (inbox) and IMAP (all mailboxes) at the
same time. repositories should not be protocol aware.
SMTP is quite important, too. ;-) POP3 and SMTP/delivery use only a
small subset of the IMAP requirements to a mailbox.
So if you would design an API 100% IMAP dependent and be blind for the
other protocols it probably would not be a problem, you could use it via
a pop3 server anyway.
POP3 and SMTP requirements are simple.
I really can't imagine how the API could be designed that nobody would
say "oh, this looks a bit IMAP oriented, doesn't it?"
Currently in my JDBC/Torque implementation, I do it like I did for the
Imap-JavaMail-backend: provide a wrapper to allow access for all James
by a MailRepository implementation.
Of course sooner or later API should accessed directly.
Thats really cool. So we not need to change anything yet and can test it
and dedicite after that what have todo :-)
we should extend/fix/refactor or repository architecture first, with
IMAP in mind of course.
What IMO could be done now is deprecating MailRepository and switching
to MessageRepository with repository generated keys and no locks. A
second step could be putting the mailbox access into a session.
Apart from that we should IMHO start from scratch. IMHO the current
MailRepository implementations are no suitable to extend and refactor
them until they fulfill all IMAP requirements. In my eyes their approach is to
different from the imap requirements.
+1
this does not neccessarily mean we have no IMAP development going on
in parallel. but it should not drive the repository restructuring.
Well, I guess that 80% of the API will be used by IMAP server only.
I do not agree we should design the repository completely independent
from the imap development.
It doesn't help us if we do the design only with the theoretical
knowledge of imap requirements. When it is finished we would realize
that it's use in the IMAP server is inconvenient and cumbersomely.
To make it clear: Of course the API should be for general use.
Subfolders will be certainly accessed by Mailets etc., too.
Maybe, e.g. a webmailer uses the API too access repository directly.
Another goal is to make a Javamail-wrapper possible.
It should be convenient usable by all our protocols and needs.
And I fear If IMAP development does not drive repository restructuring
we'll NEVER get a result. IMO we need an agile and pragmatic approach.
I have no problem to refactor the repository. I think thats needed for
gettin new stuff workin. I hate the sentence "Never touch a runnin
system" :-P
-------------
A quick status of http://issues.apache.org/jira/browse/JAMES-502:
Because discussion of my API proposal published as
repository-proposal-3.zip at JIRA and on my website
http://www.joachim-draeger.de/JamesImap/
hibernated, I decided to start a prototype implementation which uses
JDBC/Torque with MySQL or Derby, under the working title MailboxManager.
Then I refactored the IMAP code to use the new API.
Everything works quite well at the moment. I have unit tests for all
basic operations.
I just did the integration with current James trunk.
I did it completely without changing current James code. Just putting,
some jars into SAR-INF/lib and modifying assembly.xml.
I soon publish it at JIRA, when I find the time to do the packaging with
some documentation. (It always costs a lot of time so if you want to be
up-to-date look at my svn)
For the impatient:
http://svn.joachim-draeger.de/repos/james/imap/
http://svn.joachim-draeger.de/repos/james/mailboxmanager/
My ideas to the roadmap topic:
- after publishing API with prototype running together with imap in James I
hope for some review.
- maybe we are able to make some decisions then
- we have to decide if/how to integrate the code
- for integration everything (sandbox/branch/product/trunk) is imaginable, because it does not interfere with existing code.
Joachim
That sounds really good. And for sure we will review after see your work
:-)
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
