On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
<snip>
>> 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?
perhaps one of them at least :-) 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). 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
