Fw: Mailbox Objects
- From: Peter Williams <peter newton cx>
- To: balsa-list gnome org
- Subject: Fw: Mailbox Objects
- Date: Thu, 18 Nov 1999 23:10:17 -0500
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]