james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zsombor <gzsom...@gmail.com>
Subject Re: [MailboxManager] API Design
Date Mon, 05 Nov 2007 17:31:40 GMT
On 11/5/07, Paulo Sergio <pauloslf@gmail.com> wrote:
>
> 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?


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

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