Lex (and other Celeste users),

Personally, I don't *think* I'd really want the features mentioned
in 3, 4, and 5, but don't count my vote on this since I'm not a
current user and have scarely experienced those features.

I haven't used Celeste for a while, but I do periodically dump all
my current messages into Celeste. I've been doing this for a long
time, so I've now got some huge Celeste mail files, and I can see
that scale problems that have arisen.

The precursor to Celeste, Babar--which was used pretty heavily at
Xerox Parc and ParcPlace Systems for a number of years--had a couple
of design features that helped with the scaling problem. First, the
.index file was kept as a BTree, so the entire file didn't need to
read into memory at startup. A certain number of BTree pages were cached,
so a working set of index entries was usually in memory. However, Babar
did not have the filter functions that Celeste has, and scanning 10,000
BTree entries when filtering the entire mail database would likely
be slower than scanning Celeste's memory-resident data structure.
Thus, I think a better fix for the slow startup time for large mail
databases would be to switch to a binary format for the .index file
that can be read much faster than the current text-based format.
As I recall, parsing the large integers used to represent timestamps
and message ID's is very slow.

The other feature that Babar had was lazy updating of message
index entries. If you selected a category with uncached message
index entries, the message list pane would start empty and fill
one message at time. The process of fetching index entries continued
in the background, so if you scrolled down quickly you could catch up
to the point were entries had not yet been read in and watch them
filling in, one at a time. This took a little getting used to, but
it did mean that you could start doing things almost immediately
after selecting a large category. Perhaps something similar would be
useful for Celeste.

Of course, before doing any performance hacking, one should study
where the time is being spent (which I haven't done!). Both BTrees
and lazy evaluation add complexity and its only worth adding complexity
if it makes the system significantly more usable.

	-- John



At 10:05 PM +0500 1/20/01, Lex Spoon wrote:
>A while back we had some discussion about various features in Celeste. 
>Little was resolved, we all just went along with what's in the image,
>and I personally just coded my own image to taste and forgot about it. 
>Well, I'm now starting from a new image and bumping into these things
>again, so I'd like to revisit a few of these things.  Probably at least
>o few people will think the same as I, but then again, there's not a
>patch in here that *someone* doesn't like.
>
>To get started, I'd like to take a quick poll about a few things.  I'll
>post the summary in a week, and we can get an idea of how people are
>using Celeste and where we should go next.  If you've ever used Celeste,
>your input is appreciated.  Feel free to elaborate, too -- this isn't a
>raw vote count, I just think everyone would like to see what everyone
>else wants out of this thing.  And finally, just so you know, I'll
>include your full response in the summary unless you ask otherwise -- so
>if you'd rather be a stealth Celeste user but still be in the survey,
>you'd better tell me.  :)
>
>
>Cheers!  -Lex
>
>1. How much do you use Celeste?
>
>2. What do you think of showing a maximum of 200 (or whatever) messages
>at a time?
>
>3. What do you think of the status line saying "Showing X of Y messages
>in Z"?
>
>4. What do you think of the "custom filter move" function, where you
>click and your message goes to an appropriate category automatically?
>
>5. What do you think of the auto-selection of custom menus, where you
>click "custom" and it will try to pick an appropriate filter depending
>on what message is selected?