Hi Guys!

It's cool to see more people interested in Celeste - I use it, I like
the power of being able to shape a tool I use a lot. Would be cool to
have more fellow users. I'm glad to help anyone try to figure out or do
this or that.

Anyway, I repeat Lex's request of a few weeks back - if you're
discussing Celeste, it helps if you do it in reference to how it
actually works.

For example, there may be a mapping between Celeste's flat categories,
and nested folders (like the IMAP model assumes, also like "each message
a file, folders are nested directories") - but it's not trivial. 

It would be more useful to say "I think the mapping could be like this"
or "I would like Celeste refactored so I can plug in my nested folders
model instead of flat categories and reuse most of the code", or better
yet, to just code it. Saying "let the Square be Round" is just not
likely to work.

[About different backends]
Actually, the latest SqueakNews mentioned GemSqueak (The Sugar guys
really do amazing Squeak work), which got me thinking about doing a
Gemstone link. Gemstone is available NC for Linux, and having a real DB
backend would free Celeste of many worries...

Daniel

Bijan Parsia <bparsia at email.unc.edu> wrote:
> On Sat, 3 Nov 2001, Bert Freudenberg wrote:
> 
> [snip]
> > Back on topic: I think I won't switch to Celeste before the file format is
> > not compatible with the standard unix stuff. Maybe there should be various
> > backends? One for the monolithic message file, one for your "each message
> > a separate file", one for "each message folder a file, nested folders are
> > directories (my pref)" - and then, IMAP support would be cool, too :)
> 
> One for Minnstore, one for Pointrel, one for MySQL, one for Gemstone,
> etc. etc...
> 
> ...and be able to mix and match all o' these...
> 
> I really like this (oh, and I'd love to have MailDB refactored a bit, it's
> actually a pretty damn useful persistency mechanism, if a bit hard to
> handle at the moment). The question, of course, is how much of the
> capabilities of the backend do you want to shine through. Using these
> various stores merely as a replacement for the .messages file should be
> reasonably straightforward...you just have to alias (or make
> pluggable) the current msgID assignment & lookup functions. The table of
> contents list is cached in image (i.e., the indexfile) and the categories
> are just named lists of msgIDs (one day to be hierarchical...I
> hope) (although, I think lex may be doing something with categories as
> named lists of dynamically generated msgIDs, i.e., the results of
> filtering a la Evolutions virtual folders).
> 
> That's one pretty cool thing about Celeste, it's fairly easy to bend to
> your will, within certain limits.
> 
> Cheers,
> Bijan Parsia.