robert burrell donkin wrote:
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?
perhaps one of them at least :-)
I was sure :-)
IMAP is a difficult protocol. making a implementation which performs
ok is very difficult. it exposes issues which less difficult protocols
do not (at least when you only require adequate performance).
I think the idea behind the current implementation is to create
something compliant and working. This is already a big goal for James
(as for years we only had an incomplete implementation in a sandbox).
Of course we can change our roadmap (we don't have one, so it will be
easy ;-) ) if you think you can contribute more work on Imap.
I would avoid big changes to the architecture if we have no committers
actively taking care to make the effort concrete/complete.
as soon as different protocols start getting different storage
sessions, the session starts to become more and more protocol
specific. the clean separation between processing and data access
states to erode.
the existing requirement for protocol specific mailboxes introduces a
coupling between the mailbox and the protocol processing code. i
wouldn't describe the proposal as less coupled, just that the existing
coupling is made more explicit.
optimizing a call-based API usually means adding more and more calls
that are more and more tightly coupled to the particular use case.
every call added to an interface breaks compatibility. every call
introduces another capability that fewer and fewer possible storage
solutions will be able to meet.
so, i wouldn't say that the proposed API is more generic but is more
maintainable since it can be fully analyzed a priori.
- robert
I can't say I understand you, but thank you anyway for trying to explain!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
