[Top][All Lists]

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

Re: [bug-mailutils] Merging libraries (was Re: Mailutils 0.3

From: Alain Magloire
Subject: Re: [bug-mailutils] Merging libraries (was Re: Mailutils 0.3
Date: Tue, 25 Feb 2003 21:28:50 -0500 (EST)

> Just an idea regarding object structures in the new libmailbox.
> The mailutils objects have many things in common, so it may prove
> useful to create a 'generic object' structure which will provide
> the basic object functionality, e.g.:
> typedef struct _mu_generic_object *mu_generic_object_t;
> /* generic methods available to any object */
> struct _mu_generic_vtab {
>        int    (*create) (mu_generic_object_t *);
>        int    (*close)  (mu_generic_object_t);
>        int    (*destroy)(mu_generic_object_t *);
>        int    (*notify) (mu_generic_object obj, int event, void *data);
>        /* something else? */
> };
> /* generic object: a parent of all mailutils objects */
> struct _mu_generic_object {
>        int      type;         /* Type of the object */
>        size_t   size;         /* Size of the object instance */
>        struct   _mu_generic_vtab vtab; /* generic methods */
>        /* Possibly something else? */
> };
> Now, mailbox structure would be defined as follows:
> typedef struct _mu_mailbox *mu_mailbox_t;
> struct _mu_mailbox {
>        struct _mu_generic_object gen; /* This provides basic methods */
>        struct _mu_mailbox_vtab vtab;  /* mailbox-specific methods */
>             /* Mailbox-specific data follow */
>        unsigned int messages_count;
>       /* ... etc ... */
> };
> Any particular mailbox implementation is built upon mu_mailbox_t in
> the following way:
> struct _mu_mbox_mailbox {
>        struct _mu_mailbox base;               /* basic mailbox functionality*/
>             /* Mbox-specific data */
>        char *filename;                        
>        lockfile_t  lockfile;
>        /* ... etc ... */
> };
> Opinions?

A single rooted class ... The same way Java  is doing java.lang.Object.
Ok, sounds good to me.  The disavantage with single root:
 - third parties that wants to play along, must implement
   that root class also.

But I do not think it is that bad, the advantage as you pointing out
its the overall consistency, being able to down cast any object:

        message_t message = message_create(...);

or rather, with the function wrappers:

        message_t message = message_create(..);
        mu_object_notify((mu_object_t)message, ..);

So in that scheme the mailbox_t vtable would look like

struct _mu_mailbox_vtab {
  struct _mu_generic_vtab base;
  int (*_get_message)(...);
  int (*_messages_count)(...);

All objects must have "struct _mu_generic_vtable base" as the first
field in there own vtable.

I would still suggest that we follow the plan match that you propose
earlier, meaning to do changes in phases, and in each phase to get
the repository in working shape even if that means duplication of some
work.  The reason, is that my schedule is hectic and may not be available
to respond over a long period and would hate to leave CVS in a flux/broken.

To recap your suggestions:
Phase 1:  getting the new allocation scheme in the objects(refcount and
  nuking of owner)

Phase xx, in no order:

- namespace mu_ prefix

- vtable transition

- breaking in low level libs (mbox, pop, imap, mh, maildir) in there
directories and abstract them from the framework.

etc ...

I would also recommand that we document mailutils/doc those changes
right away instead of the usual "wait 'till the last possible minute
to do docs and forget about it" attitude 8-).
That goes for testing, but I did not have a change to learn dejagnu yet.

Any hint on a good time to branch ?  Even, when being carefull, I can
see some serious breakage in the repository  8-).

reply via email to

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