robert burrell donkin wrote:
I think this is a step back from the current design or it simply regards
something we already trying to solve differently with the handlerapi.
the current API design is flawed: this is just one way to fix it.
Let me better approach this discussion: what is your knowledge of the
whole james code (in particular the smtpserver/handler), how it changed
in 2.3.0, how it changed in trunk, then in the 2 experimental branches
and now in the handlerapi-experiment?
I think that a command pattern having an ImapCommand as the command
cannot be the api to the backend (the MailboxManager). The
MailboxManager shoudl be able to provide results for Imap, for POP3, and
for other protocols we may want to provide.
then it's already a failure :-)
mailbox is coupled to IMAP and the more you optimize, the tighter than
coupling will become
What you propose have IMAP all the way: I don't understand how you can
say it is more generic and less coupled. Am I missing the whole point?
from an outsider's perspective, given you've already opted for that
approach, the question is simple how best to organize that coupling.
the way you've chosen prevents anyone maintaining independent
implementations.
No, we didn't opted. But we are working on a specific direction in the
last months. Of course if you jump in and propose something in the
opposite direction we want to understand the benefits before stopping ;-)
About the command pattern applied to our services we are already working
on a common infrastructure to reuse part of our network layer between
services and prepare for asynchronous handling: you can look at the
smtphandler in james 2.3 for the first implementation, you can look at
the handlerapi-experiment for a more advanced solution we're working on
as an experiment.
the best plan would be to use SEDA
this requires use of messaging APIs
The architecture now in handlerapi-experiment supports SEDA
(specifically it has been wrote with MINA in mind).
And there is a command pattern.
from what i can tell from looking at the newer code, you seem to be
moving towards a messaging API but the interfaces suffer from the
usual faults (too complex, probably unmaintainable going forward).
maybe you'll get there in an iteration or two.
I still don't understand if you talk about a storage api or a protocol
api. The 2 issue are completely different and should not be mixed, IMHO.
When you started talking with Joachim I thought you wanted to discuss
the storage layer, but most of the last messages bring me to the
protocol layer: I'm confused.
I will reply to remaining of this message once I'll know what is your
knowledge of the rest of James code.
i'm not interested in heading again down a road that's bound to end in
tears. if i decide that james is too slow for me to live with any
longer, i'll probably just hack my local fork.
Of course this is an option: my preference is to see your local fork in
a sandbox in the james project. This way we can see real code and bettwe
understand what you are trying to explain and show us the performance
gain of your solution.
Personally I value a good set of working code much more than any
discussion about messaging api vs method/interface oriented (OOP) api.
I bet I will support you much more as soon as I will be able to
understand you better.
i'm interested in having a IMAP implementation that i don't have to go
and make a cup of tea when i'm opening my mailbox. i'd also like an
implementation that could handle my full mailbox not just the 5-10%
that i'm forced to load into it ATM.
+1, but I simply don't *currently* get how
http://svn.apache.org/viewvc/james/server/sandbox/design-doodles/imap/messaging-api/imap-mailbox-class.png?view=markup
can increase our performance by 5x.
i am disappointed that you let me waste time (that i could have spent
more valuable elsewhere at apache) outlining designs that you were
never going to accept. next time please be clear up front. that way, i
wouldn't have to pull jochen's implementation apart ;-)
I never told that we would never going to accept your code:
1st: it is not up to me to decide this, but of the whole PMC. So my vote
count as 1/10 of the final decision.
2nd: I still don't understand the real content of your proposal: we just
met, we need to understand each other, first.
3rd: just provide new code that works better and you will receive a lot
of +1 by pmc members, don't worry ;-)
4th: I don't use IMAP, I'm just interested that we keep the imap module
consistent with the remaining of james. IMAP is already very different
from the rest of James in many aspect and the goal is to add more
synergy between the modules. Joachim did the great work, but it is only
a first step: current imap support is still experimental and basic.
5th: the fact that I'm trying to understand (wasting my time? ;-) ) what
you propose and I'm replying to you means that I'm interested in what
you propose: I could simply ignore your message otherwise and work on my
own things ;-)
but thanks for taking the time now to let me know that you have your
new design and you're not interested in alternatives
- robert
I think you misunderstood me ;-)
I thought you were the "last arrived" between james committers and I
want to make sure you know what we currently have and where we are
spending our hours. You may discover that we already did what you are
proposing or that we already evaluated it, or maybe you already know
everything about James and you have the keys to the power: I don't know
but I'm here to understand.
Just look in the mailing list archives and see how often I rejected code
proposed to be included in trunk and you'll see that it didn't happen so
often.
I try to restart from scratch and summarize.
I think our main layers are
1) Protocol handling
2) Message processing
3) Message storage
Most of the Joachim work is about the message storage.
Most of the protocol handling code, imho, can be made common between our
line based protocols (using the command pattern and maybe the memento
for the session, like you propose).
Initially I thought this thread was about 3, while your diagrams seems
to me about 1: this is why I'm confused.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
