james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [MailboxManager] API Design
Date Mon, 05 Nov 2007 16:09:20 GMT
On Nov 4, 2007 8:21 PM, Paulo Sergio <pauloslf@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?

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

View raw message