Fw: Mailbox Objects



On Thu, 18 Nov 1999 23:09:52 I wrote:
> Stuart (& everyone else),
> 
> I took a look at the new folder code. My view was a more complete rewrite
> of the folder code (do we rely on any Mutt folder code? ... Mutt... sigh); it
> would have to be developed parallel to the regular code so that Balsa would
> still be usable. 
> 
> Anyway, it seems like a good idea to have a conception of what a Mailbox
> object should be able to do. This is what I've come up with:
> 
> Mailbox {
> 	Public Data:
> 		gchar *name -- human-friendly name given to it
> 		guint32 num_messages -- duh
> 		gchar *uri -- Mailbox expressed as a URI: mhdir:/var/spool/mail/peter/
> 			imap://user@host.com/INBOX
> 			pop3://user@host.com
> 		flags flags -- including CanHaveChildren, IsWritable, IsSortable, etc.
> 		perhaps other config information such as 'gboolean check_me'
> 	Private data:
> 		guint32 reference_count -- duh
> 		mutex lock -- For when multithreading comes
> 
> 	Methods:
> 		Mailbox *new( gchar *uri ) -- Use the URI to figure out what type it is
> 		void explore_children( Callback child ) -- Used for mailboxes that
> 			can have children (MH, IMAP)
> 		void check -- Start the checking process; on remote MB's, spawn off
> 			a thread and do what needs to be done. On locals, prolly stat()
> 			the file and maybe start a new thread if need be
> 		void destroy -- Close the mailbox and delete it if possible.
> 
> 		MailboxPosition *get_start_position( void ) -- Get a mailbox position
> 			representing the start of the mailbox. The key is that how 'the start
> 			of the mailbox' is stored is implementation-dependent; this masks
> 			that problem.
> 		MailboxPosition *get_last_position( void ) -- As above
> 		void advance_to_next_position( MailboxPosition *pos ) -- duh
> 		void advance_to_prev_position( MailboxPosition *pos ) -- duh
> 		Message *get_message_at_position( MailboxPosition *pos ) -- this should
> 			in some way count as a ref for the mailbox, because if we close the
> 			mailbox while the message still exists....
> 		void insert_message_after_position( MailboxPosition *pos, Message *msg )
> 		void overwrite_message_at_position( MailboxPosition *pos, Message *msg )
> 		void delete_message_at_position( MailboxPosition *pos )
> 
> 		and so on. Probably provide some short-circuits such as empty_box or
> 		insert_message_at_end, etc.
> 
> 		void ref()
> 		void unref()
> 
> 		GtkWidget *make_config_window -- So that we can just pop it in our dialog
> 		void save_to_config( Proplist *pl ) -- unless we use GnomeConfig
> 		vodi read_from_config( Proplist *pl ) -- unless we use GnomeConfig.
> }
> 
> I think that covers everything I've thought of so far. The generic code would do a lot:
> 	o Take care of multithreading / locking
> 	o Keep track of Message *'s that this mailbox has created, so they can be destroyed
> 	o uhhh... stuff
> I think if the generic code was robust you could have a brain-dead implementation of the
> various mailbox types and it would work.
> 
> Does this seem good? It would be a lot of work but it would be worth it IMHO.
> 
> ==============================
> Peter Williams peter@newton.cx

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



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