Hey Cees, I have been thinking about this program off and on for years and would love to bounce some ideas off you.

I have actually made a "sketch" of a package that starts it off. I call it "Squill" and, should you be interested, I have just put it on SqueakSource for your perusal.

Here are some of the major ideas and highlights.

SquillMessage wraps the MailMessage so it can offer some other things like the "tokens" (i.e., [Q][et], etc.), the #was value, if present, so that the thread can potentially link the other thread.

There is a container called SquillFolder, which can also hold other folders (a composite). The next larger-grained object is a special kind of SquillFolder called a SquillOrganizer. This decorator refers to a meta for itself called a SquillOrganizerDefinition where your filters are defined.

MaMboxParser is a quick-and-dirty that takes one of those archive files, (mbox, I think) and provides #messagesDo: which gives your block the MailMessage instance.

The program is intended to be both my email client and mailing list "manager" program. I think this will (eventually) be a fun program to write.. Let me know if you'd like to collaborate.

Cheers, Chris

--- Cees De Groot cdegroot@gmail.com wrote:

Sorry, pressed 'Send' by accident:

On 12/7/05, Cees De Groot cdegroot@gmail.com wrote:

...

references

So a method references that would return a collection #('messageid1@foo.com' 'messageid2@foo.com')...

and an index on #references that would somehow automagically add these two index entries. But that doesn't seem to work - do I need to stash these references in a separate collection that holds objects (message id -> (referenced messagse)) has a string index?

Ditto for from/to/... of course :)

Regards,

Cees

Here I might deverge a bit - why organize in static folders? One of the nice things of my current email client is that it doesn't do that. You tag stuff, don't drag it. At most, I think I'd have not containers but indexes with (del.icio.us-like) tags...

Ok, yes, this is great thinking as far as searching goes. I have long loathed navigating large trees of containers (folders) as a means of finding something. For that, the indexing/tagging you describe is much better.

But these are not conventional folders. From a searching perspective, the "folders" I'm talking about are, functionally, no different than the tagging indexing you're talking about (correct me if I'm wrong), except that the folders provide more-familiar semantics to the average Outlook bumpkin. A message will (automatically) "be" in all the folders it qualifies based on that folders indexing rules, but there is only one copy of the message, referenced from multiple folders.

The folder metaphor is useful for the "browse" use case. A newbie wants to learn about Morphic but not exactly what "tags" they should search for so they could, potentially, just open up the Morphic "folder" to see the messages that were automatically indexed there and start reading.

Folders with static indexing rules provide a means for someone to collect just the topics that interest them.

Also, the use case where we definitely want to see new messages in a single "Inbox" type of place so you can see what incoming discussions are occurring.. Maybe this could be just a huge flat indexed on #date but does that mean you can't remove the spam from it? Same for "Sent". I want to know everything I've ever sent, but that has no bearing on the fact that those sent messages are indexed in other folders too..

Because I don't know much about indexing technology, my natural inclination is to have lot of different indexed MagmaCollections (one per "folder") to compensate for the its limitations (single attribute indexing)..