I'd like to switch from Communicator to Celeste. I don't have any problems with multiple ISPs and such.
The problem I do have is simply the huge amount (well, hugeness is relative, currently nudging half a gig and all in standard Netscape 4.7* on *nix format) of stuff I have to transfer over. It can't be as simple as copying all the child directories over, or can it?
Ideas, advice and cries of "don't do it!" welcome.
Cheers
John
On Wed, 31 Oct 2001, John Hinsley wrote:
I'd like to switch from Communicator to Celeste. I don't have any problems with multiple ISPs and such.
The problem I do have is simply the huge amount (well, hugeness is relative, currently nudging half a gig and all in standard Netscape 4.7* on *nix format) of stuff I have to transfer over. It can't be as simple as copying all the child directories over, or can it?
Ideas, advice and cries of "don't do it!" welcome.
Don't do it.
Really, don't do it.
I've not yet investigated Lex's latest stuff, but having a 96meg messages file with >19000 messages is...interesting.
Not scary. Not really. Nope nope. Not really. Well, maybe a little :)
I'm becoming convinced that the current IndexFile design needs, at some point, to go. Or be updated. A fulltext indexing solution, at least for local stuff, seems to be the best solution, afaict.
Cheers, Bijan Parsia.
John Hinsley wrote:
I'd like to switch from Communicator to Celeste. I don't have any problems with multiple ISPs and such.
The problem I do have is simply the huge amount (well, hugeness is relative, currently nudging half a gig and all in standard Netscape 4.7* on *nix format) of stuff I have to transfer over. It can't be as simple as copying all the child directories over, or can it?
Ideas, advice and cries of "don't do it!" welcome.
Cheers
John
I too, would like to switch from Communicator to Celeste.
I use Communicator on WinME (at work, no choice :( ) and at home on Debian Sid with Mozilla 0.95. I tried Ximian's Evolution but just didn't/haven't really liked it.
I have 10s to 100+ mailboxes hierarchically organized. I have close to 600mb and 90,000 messages in mail.
I would love for Celeste to be able to handle that.
It seems to me (maybe incorrectly) that Celeste would need to do similarly to other clients in that the mail file needs to be broken up into multiple files, generally according to the mailbox scheme set up by the user.
In Communicator each mailbox has it's own file and index. I believe Eudora is similar.
I asked my wife the other day what it would take to get her away from Eudora. She's open to such a move but it would have to be reasonably feature equivalent and user friendly. She and my children are currently on Macs.
It would be nice if Celeste had UI choices (skins, chromes, faces, whatever). One of which was similar to the other email clients so that a migration path could be made from Communicator, Outlook, Eudora, etc to Celeste. After migrating and becoming comfortable with Celeste/Squeak then they could possibly if they choose move to a potentially different and more powerful UI.
Being able to import or use standard mbox format mailboxes would be great. I frequently join mailing lists which have either downloadable archives or archives available from the mail server. It would be nice for Celeste to handle that.
For example this mailing list is archived (back to July 01) at: http://lists.squeakfoundation.org/pipermail/squeak-dev/
I look forward to using Celeste and hopefully contributing to it's advancement once I become more Squeak proficient.
Jimmie Houchin
I think the heart of Eudora qualifies as a minimal workable email client. I would love to see Celeste taken to that level, including a nicer UI (though Eudora could also be better in this regard). It would be nice to have a global "Celeste & other comm flap", etc.
Cheers,
Alan
-----
At 5:32 PM -0600 10/31/01, Jimmie Houchin wrote:
John Hinsley wrote:
I'd like to switch from Communicator to Celeste. I don't have any problems with multiple ISPs and such.
The problem I do have is simply the huge amount (well, hugeness is relative, currently nudging half a gig and all in standard Netscape 4.7* on *nix format) of stuff I have to transfer over. It can't be as simple as copying all the child directories over, or can it?
Ideas, advice and cries of "don't do it!" welcome.
Cheers
John
I too, would like to switch from Communicator to Celeste.
I use Communicator on WinME (at work, no choice :( ) and at home on Debian Sid with Mozilla 0.95. I tried Ximian's Evolution but just didn't/haven't really liked it.
I have 10s to 100+ mailboxes hierarchically organized. I have close to 600mb and 90,000 messages in mail.
I would love for Celeste to be able to handle that.
It seems to me (maybe incorrectly) that Celeste would need to do similarly to other clients in that the mail file needs to be broken up into multiple files, generally according to the mailbox scheme set up by the user.
In Communicator each mailbox has it's own file and index. I believe Eudora is similar.
I asked my wife the other day what it would take to get her away from Eudora. She's open to such a move but it would have to be reasonably feature equivalent and user friendly. She and my children are currently on Macs.
It would be nice if Celeste had UI choices (skins, chromes, faces, whatever). One of which was similar to the other email clients so that a migration path could be made from Communicator, Outlook, Eudora, etc to Celeste. After migrating and becoming comfortable with Celeste/Squeak then they could possibly if they choose move to a potentially different and more powerful UI.
Being able to import or use standard mbox format mailboxes would be great. I frequently join mailing lists which have either downloadable archives or archives available from the mail server. It would be nice for Celeste to handle that.
For example this mailing list is archived (back to July 01) at: http://lists.squeakfoundation.org/pipermail/squeak-dev/
I look forward to using Celeste and hopefully contributing to it's advancement once I become more Squeak proficient.
Jimmie Houchin
On Wed, 31 Oct 2001, Jimmie Houchin wrote:
[snip]
I have 10s to 100+ mailboxes hierarchically organized. I have close to 600mb and 90,000 messages in mail.
I would love for Celeste to be able to handle that.
It seems to me (maybe incorrectly) that Celeste would need to do similarly to other clients in that the mail file needs to be broken up into multiple files, generally according to the mailbox scheme set up by the user.
Probably not, but that's certianly doable as things stand. You can open a celeste on a different email file than the standard "EMAIL". If one conceived of each mail file as a "folder/mailbox" (like in Eudora), you're pretty close to a Eudoraesque UI. The biggies are a interface to the multiple boxes (although some hacks with FileList should handle that) and the fact that "sent mail" won't be unified. But it's not a *huge* leap to accomodate that.
OTOH, you probably, for many things, don't *need* multiple files. What pre-LargeList Celeste is brutal on is *displaying* medium to huge numbers of messages. But you can limit what you display at any time.
[snip]
Being able to import or use standard mbox format mailboxes would be great. I frequently join mailing lists which have either downloadable archives or archives available from the mail server. It would be nice for Celeste to handle that.
[snip]
Celeste can import several different formats, IIRC.
It shouldn't be too hard to adapt MailDB and friends to use those mail formats directly. You have to move id handling out of the messages file (given that it would be in a different format) and that would add a bit to the possible fragility of the system *unless* ids were recoverable from the content alone.
Or if message ids didn't particularly matter for categorization, e.g., categories became more like Evolutions virtual (search based) folders.
Cheers, Bijan Parsia.
Hi.
I have 10s to 100+ mailboxes hierarchically organized. I have close to 600mb and 90,000 messages in mail. I would love for Celeste to be able to handle that.
Fidonet had nice stuff to hold tons of mail efficiently, especially the Squish and Jam mail storage designs. I believe that I have the standards somewhere, they seem pretty straightforward to implement. Among other things, Squish supports mail file compaction on the fly while storing new mails.
Andres.
It seems to me (maybe incorrectly) that Celeste would need to do similarly to other clients in that the mail file needs to be broken up into multiple files, generally according to the mailbox scheme set up by the user.
It might turn out this way, but I'm hoping that you don't have to.
If you do have to split the database, then I prefer the way that John Maloney has suggested: divide by time. Have a 1999 database, a 2000 database, etc. I know that personally, I rarely retrieve mesages older than a few months back, but it's not so infrequent that I'll want to retrieve a message when I've forgotten what category it was in.
Incidentally, the UI isn't very helpful if you have multiple databases. You can do "Celeste openOn: 'mail2000'", but then each Celeste window will be independent.
I asked my wife the other day what it would take to get her away from Eudora. She's open to such a move but it would have to be reasonably feature equivalent and user friendly. She and my children are currently on Macs.
We definitely need more hacker types to play with it before Jo Blows are set loose on it--email is one of the last things on a computer that you want to be difficult! In particular, it would be great to have suggestions on just what non-techies would like to see.
Alan's suggestion of a side-by-side comparison with Eudora sounds like it would be enlightening.
Being able to import or use standard mbox format mailboxes would be great. I frequently join mailing lists which have either downloadable archives or archives available from the mail server. It would be nice for Celeste to handle that.
Celeste can read and append to Unix-format mailboxes, which Eudora also uses (or at least used to use). More formats would certainly be nice, though.
-Lex
Lex Spoon wrote:
It seems to me (maybe incorrectly) that Celeste would need to do similarly to other clients in that the mail file needs to be broken up into multiple files, generally according to the mailbox scheme set up by the user.
It might turn out this way, but I'm hoping that you don't have to.
If you do have to split the database, then I prefer the way that John Maloney has suggested: divide by time. Have a 1999 database, a 2000 database, etc. I know that personally, I rarely retrieve mesages older than a few months back, but it's not so infrequent that I'll want to retrieve a message when I've forgotten what category it was in.
I don't know if it will be a requirement or not. After all there are many databases much larger than my 600mb in mail. I have a tendency not to delete mail I might want to search on for information. I am on many mailing lists that I do not actively read because of time, but I like the content and want it available for future usage. Because of this my mail storage volume will only increase.
Time is an interesting but a much more arbitrary means of dividing mail. It seperates like content and threads of discussion across all mailing lists and discussions in the maildb. This would not be a relevant point if the backen/UI provided a seemless view of the mail.
Incidentally, the UI isn't very helpful if you have multiple databases. You can do "Celeste openOn: 'mail2000'", but then each Celeste window will be independent.
I disagree. The UI is where the vagaries of how the mail is stored should become a non-issue for the user.
In Eudora and Communicator, all of the mail is in separate files according to the mailbox division of the user. The UI provides for a consistent view of the mail to the user regardless of storage.
Because I manage personal mail on two computers, I have at times put on floppy or emailed myself one of the mailboxes I had on the other computer so that I would have a consistent system. Before I built my PC (Debian Sid) I shared the Mac my wife uses with her. I was cleaning out Eudora of my mail on that Mac the other day and simply mailed myself the mailboxes I did not have. Very useful.
Okay, back to the point. :) In Eudora or Communicator the user doesn't know that mail is broken up into several files. The UI makes know requirements of such upon the user.
However, the maildb issue is resolved doesn't make me a large amount of difference as long as:
Performance is as good as it gets ie: If performance with a single file is as good as with multiple files, then okay. :)
The view to the user is not affected.
It doesn't limit capabilities to "fileout" various portions like a mailbox.
Istead of "Celeste openOn: 'mail2000'" how about "Celeste openOn: 'jhouchin@texoma.net'" or "Celeste openUserMail: 'jhouchin@texoma.net'"
This would allow for the future provision of multiple email accounts. This would also provide an opportunity to abstract the interface from the backend to the UI so that the interface is not file based. The backend handles mail storage management. The UI's only issue is the backend's API.
I asked my wife the other day what it would take to get her away from Eudora. She's open to such a move but it would have to be reasonably feature equivalent and user friendly. She and my children are currently on Macs.
We definitely need more hacker types to play with it before Jo Blows are set loose on it--email is one of the last things on a computer that you want to be difficult! In particular, it would be great to have suggestions on just what non-techies would like to see.
Absolutely. This why I look forward to when I can move my mail to Celeste. Then as a daily user of Celeste I can contribute to it's development. I will be available to fix bugs and scratch itches.
The more Squeak developers who can use Celeste the more this will be the case. Even if their time is limited. They hit a bug or have an itch, drop behind the scenes write a little code and scratch or squash. Voila Celeste incrementally becomes "the email client" of choice. :)
Alan's suggestion of a side-by-side comparison with Eudora sounds like it would be enlightening.
That would be easy to arrange.
Being able to import or use standard mbox format mailboxes would be great. I frequently join mailing lists which have either downloadable archives or archives available from the mail server. It would be nice for Celeste to handle that.
Celeste can read and append to Unix-format mailboxes, which Eudora also uses (or at least used to use). More formats would certainly be nice, though.
-Lex
Enjoying the discussion. Hope it proves fruitful. :)
Jimmie Houchin
Another possibility is to make each message a file; my mail system on the Acorn does this. I has costs on some platforms I imagine, most seem to have a minimum file size of some sort so you can waste space easily. With disk prices as they are these days, I don'timagine that is a particularly worrisome mater. It does offer an interesting sort of security in that it is quite difficult to end up deleting parts of messages and there is something vaguely transactional about it. If the index file(s) stored the relative paths of the messages then that would presuambly map to message IDs reasonably. It might even help with avoiding the redundant loading of message left on the server.
Now of course if we had machines able to use the file system we designed at Interval, indexable by content and tags etc, this would all be much simpler. Sigh.
tim
I like this scheme.
This solves or eliminates a lot of the problems associated with the various other methods. I think it could have nice performance implications also.
With all of the other schemes you have issues with deleting messages and compacting the file(s).
With the multi-file system reorganizing your mailboxes, moving messages from one mailbox to another has its own set of issues. In Communicator when a mailbox reaches a certain size its performance regarding opening the message list, etc. starts to degrade. I'll often create an archive folder (Squeak-dev-archive, etc.) and put messages of a certain age in it. You can watch communicator as it transfers messages to the new files in batches of 200. :( With the messages in their own files all that needs updated is the index. Sweet. :)
The only drawbacks I see are space as Tim mentioned, which I agree in a minimal issue in light of current hard disks. The other is performance difference between searching a large file and searching thousands of files. This may not be an issue at all. After all grep, swish, htdig all seem to do okay.
While on that subject... What are thoughts about an indexing search engine? That way we wouldn't have to scan each file on a search. Or does Celeste already have such. Forgive my ignorance on Celeste, I haven't spend much time there yet. Oops. As I reread Tim's message below I see him mentioning a system at Interval. Would be nice. :)
Jimmie Houchin
Tim Rowledge wrote:
Another possibility is to make each message a file; my mail system on the Acorn does this. I has costs on some platforms I imagine, most seem to have a minimum file size of some sort so you can waste space easily. With disk prices as they are these days, I don'timagine that is a particularly worrisome mater. It does offer an interesting sort of security in that it is quite difficult to end up deleting parts of messages and there is something vaguely transactional about it. If the index file(s) stored the relative paths of the messages then that would presuambly map to message IDs reasonably. It might even help with avoiding the redundant loading of message left on the server.
Now of course if we had machines able to use the file system we designed at Interval, indexable by content and tags etc, this would all be much simpler. Sigh.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Supercomputer: Turns CPU-bound problem into I/O-bound problem. - Ken Batcher
It would be neat to have each message in its own file, but as Tim suggests this will really stress certain file systems. I guess you can make multiple subdirectories, but IMHO this is pretty ugly!
The biggest problem we have with the disk format is that loading and saving the index file is kinda slow. This is a separate issue.
What are thoughts about an indexing search engine? That way we wouldn't have to scan each file on a search. Or does Celeste already have such.
Celeste actually has an in-memory index that makes most queries extremely fast. One big thing it *doesn't* have, is an index that's useful for doing full-text searches. That would indeed be nice....
-Lex
Has MinneStore been explored for applicability?
There are pros and cons to each of the schemes. As long as it performs reasonably well. Is robust, stable and scalable. Works on most all of the platforms Squeak does. Then I am open to it.
Hopefully within the next week or two (who knows) I'll be able to set up Celeste and get working with it on my current mail volume. It may not be ready for me to import my existing mail but possibly to use with my current mail. Or would you suggest waiting until the LargeList issue is resolved?
Thanks for your input.
Jimmie Houchin
Lex Spoon wrote:
It would be neat to have each message in its own file, but as Tim suggests this will really stress certain file systems. I guess you can make multiple subdirectories, but IMHO this is pretty ugly!
The biggest problem we have with the disk format is that loading and saving the index file is kinda slow. This is a separate issue.
What are thoughts about an indexing search engine? That way we wouldn't have to scan each file on a search. Or does Celeste already have such.
Celeste actually has an in-memory index that makes most queries extremely fast. One big thing it *doesn't* have, is an index that's useful for doing full-text searches. That would indeed be nice....
-Lex
Tim Rowledge tim@sumeru.stanford.edu wrote:
Another possibility is to make each message a file; my mail system on the Acorn does this. I has costs on some platforms I imagine, most seem to have a minimum file size of some sort so you can waste space easily. With disk prices as they are these days, I don'timagine that is a particularly worrisome mater.
This would be fine for the messages, but not for the *indexes*, I don't think. I'm guessing, for example, that your mail program uses subdirectories to handle separate "folders" ?
Now of course if we had machines able to use the file system we designed at Interval, indexable by content and tags etc, this would all be much simpler. Sigh.
Heh, that sounds pretty neat!
-Lex
"Lex Spoon" lex@cc.gatech.edu is widely believed to have written:
Tim Rowledge tim@sumeru.stanford.edu wrote:
Another possibility is to make each message a file;
[snip]
This would be fine for the messages, but not for the *indexes*, I don't think. I'm guessing, for example, that your mail program uses subdirectories to handle separate "folders" ?
Actually no, it doesn't. So far as I can work out (they don't supply the source code - can you believe it?) the indices are monlithic but each message lives in a separate file in a rather complex tree (related to the demented old Acorn file system restriction of 77 files per directory, now laid to rest) denoted purely by a number I suspect plays the role of an ID.
How about:- each index is stored in an eponymous file. each message is stored in a separate file, named in some abstract manner to make the indices as compact and easily parsable as possible. subdirectories used at system's convenience to avoid excessively large directories (Acorn can now handle 80,000 without much problem but
200,00 is considered a bad move)
Just a thought.
tim
A slightly different issue:- I'd really like it if Celeste could do digest-busting. I subscribe to a whole load of mailing lists and for most of them I get the digests. It wouldbe really nice to be able to split them up and treat them as 'normal' messages at least for the purposes of reading and replying. It's so annoying to reply to a digest and realise you left the subject as "plastics and rubberwear fetishists digest-1533935" instead of "Re: favourite talcum powder brands"
tim
I found the directions for making and loading some more strike fonts into Squeak.
The largest of these are 24 points.
I could use a few basic fonts which are larger, 30+ points, for presentations.
Can anyone suggest a source for larger fonts to use with Squeak?
Thanks.
...Tom M
Tom Morgan wrote:
I found the directions for making and loading some more strike fonts into Squeak.
The largest of these are 24 points.
I could use a few basic fonts which are larger, 30+ points, for presentations.
Can anyone suggest a source for larger fonts to use with Squeak?
Andreas Raab wrote a nice utility for incorporating TrueType fonts into Squeak (you'll need access to a Win 32 box to use it) and Bernhard Pieber wrote a neat fix for a small bug in it. You'll find them on the list as:
[ENH][Win32]RE: Font Support and
[BUG][FIX]FontPlugin glyphs for CRs (was: Re: accented font support in Squeak)
Andreas' code is well commented (you might want to alter the source to give you fonts the size you require). Note that if your Squeak is running on a Windows box, you should re-name Andreas .dll _after_ you've grabbed the fonts or the spacing will be all squiffy if you use italics.
Given a Windows box, this is probably the easiest way to do it (and you can always grab more .ttfs from the Web). I think they'll generally go up to 72 point.
Steve Swerling posted some font utilities last Wednesday which might be useful.
Have fun!
Cheers
John
There's a small stupid bug in the contour construction code for TTF glyphs. The original method states that a contour must start with an on-curve point, which is not right. TTF contours may legally consist of only off-curve points (which define implicit on-curve points between them). I've appended a method which fixes this by creating an explicit on-curve point (probably not in the nicest way, but I was short on time). Don't know if the other mails mentioned include a fix for this problem...
Cheers, Hans-Martin
John Hinsley wrote: ...
Andreas Raab wrote a nice utility for incorporating TrueType fonts into Squeak (you'll need access to a Win 32 box to use it) and Bernhard Pieber wrote a neat fix for a small bug in it. You'll find them on the list as:
[ENH][Win32]RE: Font Support and
[BUG][FIX]FontPlugin glyphs for CRs (was: Re: accented font support in Squeak)
On Thu, 1 Nov 2001, Tim Rowledge wrote:
A slightly different issue:- I'd really like it if Celeste could do digest-busting. I subscribe to a whole load of mailing lists and for most of them I get the digests. It wouldbe really nice to be able to split them up and treat them as 'normal' messages at least for the purposes of reading and replying. It's so annoying to reply to a digest and realise you left the subject as "plastics and rubberwear fetishists digest-1533935" instead of "Re: favourite talcum powder brands"
Should there really be a system that does not have procmail?
SCNR ;-)
-- Bert
Bert Freudenberg bert@isg.cs.uni-magdeburg.de is widely believed to have written:
Should there really be a system that does not have procmail?
Which is.....?
tim
-----Original Message----- From: Tim Rowledge [mailto:tim@sumeru.stanford.edu] Sent: Friday, November 02, 2001 13:40 To: squeak-dev@lists.squeakfoundation.org Subject: Re: [celeste] moving from Communicator to Celeste....
Bert Freudenberg bert@isg.cs.uni-magdeburg.de is widely believed to have written:
Should there really be a system that does not have procmail?
Which is.....?
By which you mean ?
Q1 - What is procmail ? A - Some unix program to process e-mail based on some regex-like rules
Q2 - An OS that doesn't have procmail ? A - Anything that isn't Unix/Linux ? - Mac OS 9 or earlier - Windows Anything (3.1/95/ME/NT/2000/XP/etc - other more obscure OS's
Q3 - What is procmail ? A - A rhetorical question since it's not written in Smalltalk ?
Must be Friday ;-).
-Andy-
Tim Rowledge wrote:
Bert Freudenberg bert@isg.cs.uni-magdeburg.de is widely believed to have written:
Should there really be a system that does not have procmail?
Which is.....?
Procmail is a pretty powerful mail filtering program: you've probably got it on your RedHat box. On SuSE I think it handles all the emails that the system sends to root.
The man page is, well, standard indigestible but does say:
"There exists an excellent newbie FAQ about mailfilters (and procmail in particular), it is being maintained by Nancy McGough nancym@ii.com and can be obtained by send ing a mail to mail-server@rtfm.mit.edu with the following in the body: send usenet/news.answers/mail/filtering-faq"
so I sent off for it. You never know.......
Cheers
John
John Hinsley wrote:
Tim Rowledge wrote:
Bert Freudenberg bert@isg.cs.uni-magdeburg.de is widely believed to have written:
Should there really be a system that does not have procmail?
Which is.....?
Procmail is a pretty powerful mail filtering program: you've probably got it on your RedHat box. On SuSE I think it handles all the emails that the system sends to root.
Ah, well I guess that makes sense from the name (most un-unix-like) but it won't help me much since I don't do mail on a unix machine - like most of the worlds population. Looks like another useful thing we should implement in squeak :-)
tim
On Fri, 2 Nov 2001, Tim Rowledge wrote:
Bert Freudenberg bert@isg.cs.uni-magdeburg.de is widely believed to have written:
Should there really be a system that does not have procmail?
Which is.....?
... a program for processing mails, hence the name. It can break up digests, sort messages into folders, remove duplicates (by message id), generate automatic replies, filter spam, you name it. And all this independently of the email client, so you can use whatever you like best.
For example, my personal procmail sorts all messages from various mailing lists into their folders, extracts [FIX]es for the sqfixes archive, starts the European Squeak Updates mirror whenever Dan sends a [updates] notice, forwards mirror logs to the respective maintainers (Dan for updates, Bruce for the UIUC stuff, Andreas for Windows stuff), and answers "unsubscribe" requests that are occasionally send to our list, besides receiving and acknowledging student's assignment submissions and various other stuff :)
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 :)
-- Bert
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.
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 :)
Directly accessing files that are in foreign formats is pretty awkward. It's a big design constraint, and it would put pressure on things like having a full index available for searching.
Directly accessing Unix mail files in particular is hard, because Squeak can't do Unix locking. This is a specific reason that POP is the main way Celeste gets email: POP works to and from any platform. Could you instead set up your Unix files to be accessible via POP (or later, IMAP)?
Anyway, I like the idea of having multiple *sources*. And IMAP should be one of them. Doing IMAP right would require an improved index file format, to avoid downloading the same message multiple times.
-Lex
Hi.
The problem I do have is simply the huge amount (well, hugeness is relative, currently nudging half a gig and all in standard Netscape 4.7* on *nix format) of stuff I have to transfer over. It can't be as simple as copying all the child directories over, or can it?
FWIW... I know about big email archives... my Netscape mail stuff just grew over 400mb. A small piece of advice you probably already know but just in case... Netscape's mail folder properties display is bugged, it will only report little space wasted. However, compress the folders and kaboom, the folder may be cut in half. This is especially true of Inbox, since Netscape won't shrink the file for the folder when you delete email (I think it just changes the X-Mozilla status header). So all the emails that go to any folder make it grow, while only compressing folders make them shrink, and BTW Netscape's count of wasted space can be grossly incorrect.
Andres.
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Andres Valloud -
Andy Stoffel -
Bert Freudenberg -
Bijan Parsia -
Duane Maxwell -
Hans-Martin Mosner -
Jimmie Houchin -
John Hinsley -
Lex Spoon -
Tim Rowledge -
Tom Morgan