You are viewing a plain text version of this content. The canonical link for it is here.

Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2007/10/26 23:29:18 UTC

[MailboxManager] API Design

from https://issues.apache.org/jira/browse/JAMES-808

> Currently the implementation of the FETCH command is not very efficient. For example to
> retrieve one mail the following conversions will happens:
> 1, the backend creates a MimeMessage from a file/database blob/thin air/etc
> 2, the frontend converts into a byte array, with correct CRLF line endings. (I don't get, why it's
> needed, every incoming MimeMessage is already in this format, isn't it ?)
> 3, the frontend appends it into a StringBuffer in the FetchCommand class
> 4, after some String manipulation it gets sent over an InternetPrintWriter which checks also that
all line endings in correct style.

this mess is the primary reason why the current implementation is
unreasonably slow. i've been running alternative code on my local fork
and the implementation is now quite enough to be usable.

> I'm not sure that the whole thing is absolutly necessary.

i'm sure that it is unnecessary

IMHO the approach in JAMES-808 is the right one (adding more function
and options to http://svn.apache.org/repos/asf/james/server/trunk/core-library/src/main/java/org/apache/james/mailboxmanager/MessageResult.java)
but there are a few broader design issues around MailboxManager that
i'd like to throw open for wider debate

in terms of general API design, i tend to prefer to use subsidary
objects to tie together data. so (for example) i prefer a Headers
interfaces and a getHeaders method rather than adding three or four
header related methods into the general API.

AIUI MailboxManager was intended to be a general API without coupling
to any particular protocol (please jump in if i have this wrong). if
this is still a useful design requirement then we need to do something
a little more sophisticated.

in particular, the structure use cases are difficult. here, IMAP needs
to know about the outline structure of a message: if it's a mime and
if so, it's composition. JAMES-808 approaching this by returning
protocol specific values coupling the API to IMAP.

i've been considering using Mime4J instead to allow generic
information to be obtained about the structure. this requires (as
jochen suggested) factoring out a suitable interface for the pull
parser. i hope that this would be good enough to allow backend
optimisation without coupling so strongly to IMAP.

opinions?

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [MailboxManager] API Design

Posted by Zsombor <gz...@gmail.com>.

On 11/5/07, Paulo Sergio <pa...@gmail.com> wrote:
>
> Hi Robert,
>
> On 11/5/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> >
> > On Nov 4, 2007 8:21 PM, Paulo Sergio <pa...@gmail.com> wrote:
> > > Hi all,
> >
> > hi paulo
> >
> > > i've been following the  discussion  and  i would like to give my
> > opinion
> > > (although i'm not an expert).
> > > i think we are forgetting an important thing, we are designing an API
> > > thinking about the existent protocols, although i think we should
> think
> > also
> > > in  what's next :) .
> > >
> > > In my case, i'm currently working in a web-service backend for james
> > using
> > > IMAP as a "front end protocol". Now i would like to start working in a
> > push
> > > mechanism, and i think about implementing IMAP Idle, i would have a
> > server
> > > sending the notification to james server, witch then would send the
> > > notification to the client.
> > >
> > > Well, this is one of the problems i think james has (correct me if i'm
> > > wrong), it lacks any type of push mechanism.
> > > In my case the server could send a session id to james, indicating
> what
> > > client should retrieve the new mails, the problem would be to get the
> > > session of the user that should be notified..
> > >
> > >
> > > in my opinion i believe we should have some king of way of sending a
> > > notification/event to the mailbox or even  better to any session,
> these
> > > would be send by an external server (my case) or by events sent by
> james
> > > server (ex:  when a message is received, check if the user is
> connected
> > and
> > > if it is send a notification to the session)
> >
> > ATM the API allows mailbox listeners to be registered but the current
> > interfaces aren't great. a single method accepting an event is more
> > concise and extensible than including all calls in an interface.
> >
> > IDLE was touched upon earlier. Zsombor suggested that listeners would
> > registered at the mailboxmanager level. if the API were switched to
> > use events then every listener could receive events for every mailbox
> > and then ignore any that were of no interest. novel events could be
> > injected into the system by the backend implementation. listeners
> > would ignore any events they did not understand.
> >
> > would this mechanism be good enough?
>
>
> i believe so, but you mean  that each  user connected would be able to
> register as a listener and then be notified when something happens?
> what about notifications from an external service ? how will these work?


With shared mailboxes and the NOTIFY extension the user can receive
notifications about new mails. I don't know what do you want from external
services, and how it is related to the IMAP protocol. Probably you can
hijack this infrastructure, to add some custom IMAP command and response,
but in that case, you have to write a specific client too, but I think it's
simpler to write your own protocol, and own little server application.

BR,
 Zsombor


ps. however I hope that you can contribute to the IMAP module, anyway :)


Thanks,
> paulo f
>
> another open question is whether an explicit API session would be a
> > useful to tie things together. something like a session would probably
> > be needed to reduce the number of factory method calls required to
> > obtain an API for a particular mailbox.
> >
> > - robert
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> >
>

Re: [MailboxManager] API Design

Posted by Paulo Sergio <pa...@gmail.com>.

Hi Robert,

On 11/5/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
>
> On Nov 4, 2007 8:21 PM, Paulo Sergio <pa...@gmail.com> wrote:
> > Hi all,
>
> hi paulo
>
> > i've been following the  discussion  and  i would like to give my
> opinion
> > (although i'm not an expert).
> > i think we are forgetting an important thing, we are designing an API
> > thinking about the existent protocols, although i think we should think
> also
> > in  what's next :) .
> >
> > In my case, i'm currently working in a web-service backend for james
> using
> > IMAP as a "front end protocol". Now i would like to start working in a
> push
> > mechanism, and i think about implementing IMAP Idle, i would have a
> server
> > sending the notification to james server, witch then would send the
> > notification to the client.
> >
> > Well, this is one of the problems i think james has (correct me if i'm
> > wrong), it lacks any type of push mechanism.
> > In my case the server could send a session id to james, indicating what
> > client should retrieve the new mails, the problem would be to get the
> > session of the user that should be notified..
> >
> >
> > in my opinion i believe we should have some king of way of sending a
> > notification/event to the mailbox or even  better to any session, these
> > would be send by an external server (my case) or by events sent by james
> > server (ex:  when a message is received, check if the user is connected
> and
> > if it is send a notification to the session)
>
> ATM the API allows mailbox listeners to be registered but the current
> interfaces aren't great. a single method accepting an event is more
> concise and extensible than including all calls in an interface.
>
> IDLE was touched upon earlier. Zsombor suggested that listeners would
> registered at the mailboxmanager level. if the API were switched to
> use events then every listener could receive events for every mailbox
> and then ignore any that were of no interest. novel events could be
> injected into the system by the backend implementation. listeners
> would ignore any events they did not understand.
>
> would this mechanism be good enough?


i believe so, but you mean  that each  user connected would be able to
register as a listener and then be notified when something happens?
what about notifications from an external service ? how will these work?

Thanks,
paulo f

another open question is whether an explicit API session would be a
> useful to tie things together. something like a session would probably
> be needed to reduce the number of factory method calls required to
> obtain an API for a particular mailbox.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>