Kervin L. Pierre wrote:
Right. Common flags, such has those declared manatory by
the IMAP RFC can be left as 'calculated properties' by the
backend. In MAPI, The 'messages seen' property is calculated
by the container ( folder ) and is retrieve by a single
property request. The folder object knows when a message is
added, and knows when a message is deleted, so it does not
ever have to traverse the messages to count them.
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
to traverse the messages" seems to imply that.) And also keep in mind
it wouldn't just need to know when they're added/deleted, they'd also
have to know when the flags are set/unset.
Also property searches are very close to the unlying 'data
store', ie. database, file system etc. A data store that
has a very effecient search capability will return those
values near instantly. For example if the 'backend' interface
is implemented on an embedded SQL database. Eg. a 'Get all
unseen in the *entire* server for this user' is translated
to...
SELECT COUNT(*) FROM seen_flag_table
WHERE id IN
(
SELECT message_id FROM Messages
WHERE USER_ID = some_id
)
If you know you're going to have to support Unseen, why not:
SELECT COUNT(*) FROM Messages
WHERE USER_ID = some_id AND Seen
Why not optimize for a requirement you know is going to come? Unless
you really mean "near instantly" and it holds true when there are
millions of messages in the store.
By the way, I know the above is not supposed to be referring to a real
schema, but keep in mind that a message actually belongs to a mailbox,
and mailboxes have a many-to-many relationship with users (IMAP offers
shared mailboxes).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
