[celeste] moving from Communicator to Celeste....

Bijan Parsia bparsia at email.unc.edu
Sat Nov 3 21:00:17 UTC 2001


On Sat, 3 Nov 2001 danielv at netvision.net.il wrote:

> Hi Guys!
> 
> It's cool to see more people interested in Celeste

Hmm. I don't think I add to the *more* total :)

[snip]
> 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. 

Well there are many possible mappings, I'd wager, but I'm not sure it
matters in at least the following sense: I'm pretty content to have
categories *along side* any other mechanism. Now, whether in such a
scenario categories would still be global to a message set (i.e.,
mailbox) or local to a message set/file (like the #openOn: strategy would
suggest) are things which should be decided, or, at least, allowed for.


> 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",

I think I did say some stuff like that :) A lot depends on what level you
want the capabilities of your backend to show through.

Putting the "celeste model" on top of *any* backend is just a matter of
mapping msgIDs + access methods into that backend. The organization of the
backend matters *only* in how it complicates the access method.

The key method being IndexFileEntry>>rawText which uses
MessageFile>>getMessage:at:textLength.

Assuming the right adjustments, a MySqlIndexFileEntry's #raw text might
have something like:

	^database getMessage: msgID

Which translated into a sql query in MySqlMessages, instead of a file
read.

IOW, you *can* use the current Celsete model ontop of the storage backend
of choice, with the added benefit of automatic caching of the index and
category files.

(Here, I think some refactoring could help, at least an abstract
IndexFileEntry class.)

On the flip side, any enhancments to Celeste categorization can be layered
ontop of just about any organization, including the current flat
files. Hierarchical categories are just a matter letting the category
dictionary entries hold other categories (probably worth having a specific
Category object at that point). Oh, and some ui stuff :)

> or better
> yet, to just code it.

Well, faster said than done :)

> Saying "let the Square be Round" is just not
> likely to work.

I hope I've made it clear that I, at least, wasn't saying anything of the
sort :)

> [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...

Well, some.

If we're satisfied in the split as I pictured it above (i.e., Celeste
still doing its own thing inside the image) then things are simple. A
harder task is to try to let some of the advantages of a backend filter up
to the Celeste user in a coherent way. One (nasty) option is emulating the
features of a backend in the Celeste model, for each new type of
backend. *Some* degree of this might be worth while (e.g., getting some
sort of hierarchical view in there).

Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list