Kervin L. Pierre wrote:
Joe Cheng wrote:
Just so we're clear... you're talking about keeping a cached count of
unseen, recent, etc. on the folder object itself? ("Does not ever have
Depends on the object that implements the 'backend'
interface.
Oh, OK. I thought we were talking about implementation, not interface.
But that does not have to be a in-memory cache.
Yeah, sorry, I meant "cached" as in stored somewhere for easy access.
You're right. I was thinking a model that would let
the component consumer set arbituary properties on
messages. That way a new property is a 'name','id'
pair in the properties table. The IMAP RFC says that
arbituary properties MAY be allowed.
In my example 'seen_flag_table' would be a generated
table name that maps to the 'seen' flag, and would
have been looked up by name or id.
Don't get me wrong, I think it's totally great for the model to support
arbitrary flags. I just don't know why you wouldn't *also* add explicit
support for the core flags (and whatever other scenarios) that you know
100% of IMAP sessions are going to hit very hard, if it would improve
performance.
As another example, a lot of IMAP (and even POP) clients will only ask
for a message's header the first time around. A good design should
recognize that and not force the API client to fetch the whole message
in such a situation. (Don't bother responding about this specific case,
it's just an example--I'm just trying to make the point that the store
should not let performance suffer in the name of generality, unless
there is a very good reason.)
Great to see someone really thinking through these issues on this list!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
