Re: Writing a GNOME mail client.

[Scott Wimer <scottw dev cgibuilder com>]

Matthias,

The problem with the file system approach is that it only will cover 
a simple model of the end user environment.  Granted, it would also
be potentially easier to implement.  However, I fear that the time
spent implementing it would endup being tossed because the model just
doesn't fit a wide enough range of environments.

I keep my email and web stuff on separate partitions.  So, hardlinks
won't work.  I'd like to keep mail synced up at work and home, once
again hardlinks aren't going to do the trick.

Using filenames for IDs is likely to result in name collision because
the Messages are showing up from so many different sources.

Basically, at the heart of it, we're talking about the type of storage
that a database is designed for:
	* Discrete messages
	* single or multiple indexing of the messages
	* potential ordering of the messages
	* multiple ways to view the indexes to the messages

A file system really doesn't do any of that beyond storing the messages.
Granted, going with a dB for this could result in lots of space wasted.
I think an approach that stores the Messages across various directories
(probably hashed) coupled with dB indexes that point to the location of
the message would keep us from wasting space by storing the entire 
message body in the dB.

My 2 cents.

regards,
scottwimer

On Sun, 18 Apr 1999, Matthias Warkus wrote:

> +++ Sat, Apr 17, 1999 at 10:57:18AM -0700 +++
> Scott Wimer e-mails me. Film at 11. Reply right now, after the break.
> > Michael,
> > 
> > you're not talking email clients here.  You're talking something much
> > broader.  Something almost yahooish.  Organized data storage mechanisms.
> > 
> > Maybe that's something we need to turn our thoughts to as a group.
> > 
> > How can we organize the data in our life in the most flexible and easy
> > to use manner?  for all sorts of different meanings of "easy to use".
> > 
> > Maybe an architecture like this would be a start.  This is rough, I'm
> > working this up just out of the shower. :)
> > 
> >                            Message Storage System
> > A Message is any document (email, image, raw text, URL, etc)
> > 
> > Each message stored is given a unique ID.
> 
> A file name?
> 
> > (Basically, a public dB key
> > if you will).
> 
> 
> > Each Message may be tagged as belonging to any number of subject areas.
> 
> That is, hardlinked into a number of directories?
> 
> > 	In the common case, most Messages will only belong to a single
> > 	subject area.
> > 
> > An index of each subject areas will be maintained on the fly.
> 
> Directory listings?
> 
> > However,
> > this index needs to be able to be regenerated from the Messages 
> > themselves in the event of an index corruption.  This means we'd need to
> > store the tagging with the Message.
> > 
> > 
> > Standard dB tools
> 
> Such as a Unix filesystem?
> 
> > should let us build something like this.  We could even
> > make default 'Themes' of subject areas for folks who really don't feel
> > like taking the time to create their own.
> > 
> > We'll probably find ourselves needing to use gecko or something like it
> > for the display engine of the various Messages, since it can handle a
> > whole lot of data types.
> > 
> > 
> > Am I just whizzing in the dark here?  Or does this sound like a decent 
> > aproach to this problem?
> 
> It sounds like there is no need to invent a complete database system
> here; the filesystem plus some metadata is good enough.
> 
> Please, please, don't reinvent the wheel. Hardlinks are really nice.
> 
> mawa
> -- 
> Check out the Frequently Rehashed Topics on comp.os.linux.advocacy!
> <URL: http://home.att.net/~nishk1/frt-html/frt.html>
> <URL: http://members.tripod.com/~Nishk/frt.html>
> Report dead links to mawa@iname.com or Nish_Kohli@primaconsult.com.
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
> 
> 

--
Scott Wimer
play  --->    scottw@cgibuilder.com         http://www.cgibuilder.com/
work  --->    scottw@corp.earthlink.net     http://www.earthlink.net/