bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Competitors...


From: Alain Magloire
Subject: Re: Competitors...
Date: Thu, 16 Nov 2000 10:23:50 -0500 (EST)

> 
> On Tue, Nov 14, 2000 at 03:38:31PM -0800, Sean 'Shaleh' Perry wrote:
> > 
> > On 14-Nov-2000 Jeff Bailey wrote:
> > > http://www.helixcode.com/tech/camel.php3
> > > 
> > 
> > except Camel only works in GNOME.
> 
> Ayup - But it might be worth seeing if they have any ideas that we want. =)
> 

I took a closer look. There are a lot of similarities.
Probably the most interresting point is the vFolder.
Where you can group messages according to a criteria into
a virtual folder.   This is somewhat going to resemble what
we're going to do with sortbox_t and pobox_t.  sortbox_t
and pobox_t are like mime_t in the way they give you another
vision of the object. For example mime_t
mime_create (mime_t *, message_t) allows to see a message as
multipart instead of one flow like message_t.
The sortbox_t box takes a mailbox_t, but it rearranges the
messages order base on an sorting algorithm.
The pobox_t is particular, you attach messages to it and
it gives you persistency.  So if you have a message from
you local file, a message form an IMAP server, etc ...
You can close the application, restart reopen the pobox
the ref will still be around.

Anyway, this is the future. Enough already, my only
valid hand is getting tired.  Below is an interessting
extract from an interview of Miguel(GNOME).

-------------------Inteview----------
Excerpt from
URL<ttp://linuxtoday.com/news_story.php3?ltsn=1999-07-08-002-10-NW-LF>

.......

Dave: What about Balsa?

Miguel: Uh... Well, Balsa tries to be a conventional mail system.
It's just a nice interface for a conventional mail system. And, it's
pretty much the same as Eudora or Netscape Mail. Nothing really
fancy, nothing really exciting.

Dave: This new mail program you're talking about, one of the new
concepts behind it is this one big file that has all the mail in it,
and you're sort of indexed in there, and the folders are...

Miguel: Well, it's not actually a big file. It can be a bunch of
sources. You can actually split the mail, but from a conceptual
point of view, it's just a big mass of messages, right? It's just a
body of messages. And, the idea here is that you have vfolders.
vfolders are actually a result of a query on a database that keeps
track of all these files, right? So, you can actually have multiple
views of the same information, that's the idea behind this. We're
starting to do this because it's a problem we have ourselves with
mail, right? We're starting to get so much mail that it's difficult
to find all the mail to file and find information, that sort of
thing. So, it's basically trying to address a problem that we
currently have. Many free software people... free software
developers. Because you have to keep track of many mailing lists,
many ports going on. And retrieving information from the mail is
usually a pain. I have about a gig of mail, archived mail, and
finding something is not fun. We're doing this to mainly help us,
ourselves.

Dave: I see what you're saying. A lot of people can make good use of
that. I'm not a developer, but I also have about a gig of mail.

Miguel: But you have to keep track of things, right? Like, you know,
what's going on, exactly what's being designed...

Dave: Being in my line of business, I have to be on every single
mailing list on the face of the planet.

Miguel: Exactly.

Dave: My mail server has about 10,000 things coming in every minute.

Miguel: Exactly. So you need a way of organizing these things. Now,
the problem is that we're just at the tip of the iceberg. Internet
and mail are just starting to become important. I can see in a few
years where every single kid in the world, and every family in the
world having a mail address, right? Every person having a mail
address. Well, not everyone, but just picture 10% of the
population... 20%. And, uh, many things are going to be done in
mail, and you'll need a good recruiting system for that information.
And we don't have the framework now. I don't think anyone has that
framework.

Dave: At the Linux Today office, we've got one big box that's our
server that has all the home directories on it, all of our
workstations are actually just NFS-mounting our home directories. So
when I go to my TkRat, and I switch to a new E-Mail, it takes about
5 seconds to come across the 10 megabit ethernet. If it's all one
big file, is that going to be a problem?

Miguel: As I said, it's conceptually one big file, but it's not
actually implemented like that. It can be a bunch of files.
Everytime you incorporate mail into the system and you fetch the
mail, it gets indexed for you, and probably split into other
sources. Like, you can say, "I'm pulling my mail from pop but I want
to store it back into an imap server." So, you fetch it from pop,
you then store it in an imap server, or you store it in a mail file
or you store it in a directory or an image file. It doesn't matter.
Basically you have input sources, and storage backends. So you can
have multiple storage backends. And all of the information is stored
in the storage backends. For example, you can choose to keep all of
this stuff on an imap server, so you just pull it, index it, and
keep in the imap server without moving it, for example. But from the
point of view of the vfolder, which is what the end-user has access
to, what they see is this big body, and this big body is completely
indexed. So, that is an important thing. Now, in terms of user
interface responsiveness, the whole design is asynchonous, which
means that there are no blocking calls. The user interface is always
responsive. You can have multiple threads, it is not implemented as
threads, it is implemented as processes. But, it looks like threads.
It is all being done at the same time. It is pretty cool, pretty
cool.

Dave: Very good.

Miguel: It is a way of experimenting with lots of
stuff that is happening that lots of people have     
found to be useful, and now we are trying to get      
all of these ideas together.                        

Dave: When am I going to be able to actually use          
this?            

Miguel: Ah.. I don't know. That is a good
questions. We were expecting 5-6 months to have
version 1.0 released.

Dave: You know, that is one of the problems that has plagued the
GNOME development community. The technology behind GNOME is so solid
and carefully planned out, but it takes a lot of time to get these
things actually, you know, you put the floor in, and then you can
have the stuff on top of it. So, it looks like there is not a lot of
progress being done, but actually there is an incredible amount of
development being done.

Miguel: Actually, it is sort of funny that you mention that, because
we have this core. Right, this GNOME mailer core, which is called
"Camel" API. Which Bertrand did. And it's this beautiful API for
mail messaging and manipulation, and somebody took this API and
built another mail client, and it was like, Dude, wait a second,
we're trying to get this right! So, he's free to do it, but we're
still building more infrastructure on top of that. The API is so
usable now, that somebody actually went and in two weeks implemented
a mail client. And it's pretty nice! It's like a Eudora thing. But
we're aiming at the higher thing. If we can address our mail
problems now, I think we'll be able to address people's needs in 5
years. So, it's going to be a very powerful infrastructure for
people.

....




reply via email to

[Prev in Thread] Current Thread [Next in Thread]