james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Sergio" <paulo...@gmail.com>
Subject Re: [MailboxManager] API Design
Date Mon, 05 Nov 2007 16:36:34 GMT
Hi Robert,

On 11/5/07, Robert Burrell Donkin <robertburrelldonkin@gmail.com> wrote:
>
> 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?


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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message