On 1/9/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Montag, den 08.01.2007, 22:22 +0000 schrieb robert burrell donkin:
> > So I'm going to write a MailboxManager LocalDelivery and
> > LocalSieveDelivery.
>
> could you explain just a little more about these?
There is nothing magic about it. :-) Current LocalDelivery accesses
MailRepositories.
If MailboxManager is used, LocalDelivery accesses MailboxManager through
a MailRepository wrapper. A MailboxManager aware LocalDelivery will
accesses Mailboxes directly.
A LocalSieveDelivery can sort mail by a sieve script into different
Mailboxes.
right - go it now
AFAIK SIEVE scripts conceptually operate once mail has been delivered
to a user. how do you see the configuration working?
<snip>
> there are various methods to get various
> flavours of session.
Currently there are three.
The problem is that IMAP has many requirements to a backend. Many
backends successfully used for POP3 will probably never fulfill them.
perhaps it depends on the abstractness of the perspective: i suspect
that it all reduces to storing the email content and meta-data about
the email, at least for the storage.
From the other side developers maybe just don't need a full featured
ImapSession for their needs and want to use an easier interface.
That was the intention for providing different "flavors" of sessions.
MailboxSession easy to ImapMailboxSession advanced.
At the moment I'm not even sure if there should be different interfaces
and if they should be in one hierarchy or separated... It's all
possible. :-)
ATM the API is very session oriented. to access email means opening a
session with state preserved between invocations. i can appreciate
that with stateful protocols, it's going to be necessary to have
really pretty different session objects.
but i wonder whether it might be possible to factor the code so that
these stateful sessions are layered on top of more stateless
operations.
IMAP as a protocol has some commands which are naturally stateful and
some which are more naturally stateless. superficially at least, it
seems more natural to me to think about a stateful session layering
above a lower level stateless API.
but these are just ideas
> i'm a little confused about why a general API
> needs protocol specific methods. (i'm sure there are reasons but i
> don't see them ATM.)
Which methods are you talking about and how would you define them more
protocol agnostic and still fulfilling all IMAP requirements?
dunno :-)
suppose that's why i'm asking rather than proposing
Yes many methods seem to be just taken out of the IMAP protocol. But in
this stage that just means being pragmatic.
I'm also a fan of having everything general, abstract, meta, aspect
orientated, DI, semantic and foo. ;-)
that i never doubted :-)
It's really difficult to make the API general but still allow
optimizations for a well performing IMAP server that is able to serve
*many* clients.
+1
it's hard to see the right way to factor the code but IMHO it's worth
making the effort
> i've been tying to think about email from a different perspective
>
> current solutions tend to be constrained by the central position of
> mailboxes in their design. i think it's powerful to consider an email
> as an URI: a identified resource. mailboxes are then just become
> collections of resources but this seems really similar to other
> searches. perhaps the inner workings of an advanced server need not
> care whether the search is for mail in mailbox 'james', for mails from
> 'server-dev@james.apache.org' or tagged with 'james'.
That's all nice and beautiful but the goal is a backend that plays well
with an IMAP server. Unfortunately there are strong requirements, like
uids, message numbers and events.
message numbers are particular annoying :-/
but the fundamental needs of an email client should transend the protocol
for example IIRC IMAP responds to events by writing to the socket. an
HTTP based email server may push RSS (say). the basic requirement is
similar.
You describe a vision. API, server and client are still to be written.
I share many points of your critiques to IMAP as it is too complicated
and limited in some points. But in reality it is the only wide standard
to access hierarchical mailboxes from different clients for the next
years.
true
but i'm willing to play a long game :-)
I'm sure James can be a platform for researching on next-generation mail
API/client/backend and I hope for good ideas flowing in current James
backend that is able to serve via IMAP.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
