Two things I remember from a previous discussion about improving Celeste -
brought up by John Maloney if I remember correctly:

1) Why do we need special message ids? Couldn't we just use the offset into
the messages file? That seems easier to me and would do away with the
problem of duplicate message ids. I had this problem once and it is a nasty
problem. The way Celeste was implemented then meant that I could only access
one of the messages with the same id. :-( And it was very difficult to spot.
Normally, you won't realize that something is missing. I had to do a full
scan of the messages file to find that out. (You know how long this takes
with a messages file of over 200MB...)

2) Why not use ImageSegments to save the index on disk? It is binary and it
is supposed to be very fast. The main reason why I like that idea is that we
don't have to do the encoding ourselves. It is done automatically and
brought in automatically. Much less code to maintain. Another reason why
ImageSegments seem very suitable for the index is because there are no
outpointers in it, only Strings, Dates and perhaps some Booleans
(hasAttachments) and Integers (size). I also think that ImageSegments would
make the index much more flexible. Bring it in, change the class
IndexFileEntry, fill the necessary instance variables, dump it out again.

Lex, I wanted to tell you that I really like your FilteringCeleste very
much! I always wanted to use filters as the main means for organizing
messages. I even implemented a version with multiple filters once. However,
I never got around to integrate it in a 3.1 image. (Somehow Squeak always
changes too fast for me. ;-) The large list support is also great. I really
hated the maximum number of messages. Of course, I would really like to see
custom filters integrated. (And the status pane seems not work with it
anymore.)

I would really like to have FilteringCeleste integrated in main Squeak. And
to be honest, I would prefer to have one class instead of an own subclass.
However, I can understand that it may be difficult to agree on one GUI.
Perhaps a more configurable GUI would be a solution? Different users could
then decide which panes they would like to see (and perhaps even where they
are)? A configurable buttons pane might also be good.

Cheers,
Bernhard