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. For a property to be 'calculated' all the
interface has to do is mark it read only and refuse
to set() that property. Internal an an even that
affects that property, each CreateMessage() call, the
backend may increment a version of the property cached
in memory or on disk, etc. The result is that it is
responsible for the value of the property.
It really isn't as convulated as it may sound :) I've
worked with this model with Extended MAPI and it can
be made to be very fast.
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.
Right. You'd have to keep track of any property you
were interested in. But that does not have to be a
in-memory cache. It could be a separate 'seen_count'
table for instance, with a Folder_ID to count mapping
if we our backend is on an embedded database.
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
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.
Regards,
Kervin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
