robert burrell donkin wrote:
AFAIK SIEVE scripts conceptually operate once mail has been delivered
to a user. how do you see the configuration working?
Can you elaborate?
What does it happens if I'm checking my pop3 inbox after a message has
been delivered there but before the sieve script has been executed? (is
there a lock or simply I don't see the message until it has been processed?)
> 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.
The problem is efficently retrieve data.
We may want to access messages by 3 different identification mechanisms.
Then we need to return a subset of messages given specific filters
(mailbox, folder, search term, tag) and return size and some header
without running "full table scans" and without retrieving the full messages.
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.
Currently James does not support transactions for the spooling/storage:
I think that planning a refactoring we should think to support
transactions. If I'm not wrong there is no way to achieve transaction
support without some sort of session support.
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
Can you make an example? I'm not sure I understand.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
