Re: Camel

[Peter Williams <peter newton cx>]

>From what I've seen I agree that Camel is useless right now -- if it's rounded off
we might add support for it but it is pre-alpha right now. Then.

IMHO what we need for the backend a generic, extensible interface for accessing mail
folders. Something that will make MH seem like mbox seem like POP3 seem like IMAP. We
kind of have that now but Balsa's implementation of it is very rickety... My vision is
that of folder classes, something like.

===================================================================================

/* Called to add messages to a list somewhere... get_messages() in
   the class should loop through all the messages, read the data in
   a raw format, and call this function which will take care of that
   data. Message_handle is the data by which the folder class keeps track
   of a message: file offsets, index number, whatever is needed for its
   particular form of storage.
*/
typedef void (*EnumerateMsgFunc)( gchar *message_data, gpointer message_handle );
/* Same thing for subfolders of this folder. */
typedef void (*EnumerateFolderFunc( gchar *folder_path );

struct BalsaFolderClass_s {
	gchar *classname;
	
	/* Create private data for a mailbox specified by [path], whether that
	path be /var/spool/mail/peter or peter@mail.bob.com. */
	gpointer (*create)( gchar *path );

	/* Does the folder at path even exist (or have create() return NULL) */
	int (*verify_exists)( gchar *path );

	/* Loop through all the messages this folder contains and call func for
	each message. Return error indicator. */
	int (*get_messages)( EnumerateMsgFunc func, gpointer private_data );

	/* Same thing for subfolders, assumed to be of the same class as the parent. */
	int (*get_children)( EnumerateFolderFunc func, gpointer private_data );

	/* Message manipulation functions. */
	int (*add_message)( gchar *raw_data, gpointer private_data );
	int (*remove_message)( gpointer message_handle, gpointer private_data );
	#if we feel like we need it
	int (*edit_message)( gchar *raw_data, gpointer message_handle, 
					gpointer private_data );
	#endif

	/* Make sure that our changes have been recorded. */
	int (*sync)( gpointer private_data );

	/* Terminate our connection to this mbox -- sync is NOT called. Private_data
	is deallocated. */
	int (*close)( gpointer private_data );
};

=====================================================================================

I just made that up but implementing the wrapper is staightforward:

=====================================================================================

int mailbox_add_message( gchar *raw_data, BalsaBox *box )
{
	return box->class->add_message( raw_data, box->private );
}

etc...

void balsa_add_class( BalsaFolderClassData *data )
{
....
}

void balsa_mailbox_new( gchar *path, gchar *class )
{
...
}

=====================================================================================

Then you just have to implement four different protocols ... :-P. The idea is that 
each one is in a separate library so they're independent and modularized. Anyway, should
I get this demo code in a compilable state?

BTW, I do like the vfolder system, but that is WAAAY separate from message transport.

On Tue, 15 Jun 1999 01:14:57 David Fallon wrote:
> >From my fairly preliminary investigation, camel is waay far away from being
> alpha, much less useful for balsa. That, and I disagree with some design
> decisions they're making... The point is to try and build this
> "all-encompassing", and very generic, message handler... I think it would be
> a *lot* more useful to skip the abstraction stuff, and just build a series
> of libraries to provide access to the various protocols, (libpop3, libimap4,
> etc.). Not only will balsa benefit, but then anyone else out there who wants
> to use the pop3 protocol (say, all those silly people that write mail
> checkers for the toolbar), will have the library to use also.
> 
> Check out some of the proposed camel structure:
> http://cvs.gnome.org/lxr/source/gnome-mailer/devel-docs/query/virtual-folder
> -in-depth.txt
> 
> For the most part, I think this is waay too abstract to be useful, but there
> are some good points in here (esp. the message notation concept near the
> end.) Something to keep in mind...
> 
> Check out the rest of camel in:
> http://cvs.gnome.org/bonsai/rview.cgi?dir=gnome-mailer&cvsroot=/cvs/gnome
> http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=gnome-mailer/de
> vel-docs
> http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=gnome-mailer/ca
> mel
> 
> So, given that, where do we start, peter? :)
> 
> 
> -- 
> 	FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail balsa-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.

==============================
Peter Williams peter@newton.cx