[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(...);
((mu_object_t)message)->vtable->notify(..);
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-).
- Re: [bug-mailutils] Mailutils 0.3 released, (continued)
- Re: [bug-mailutils] Mailutils 0.3 released, Alain Magloire, 2003/02/17
- [bug-mailutils] Merging libraries (was Re: Mailutils 0.3 released), Sergey Poznyakoff, 2003/02/18
- Re: [bug-mailutils] Merging libraries (was Re: Mailutils 0.3 released), Alain Magloire, 2003/02/18
- Message not available
- Re: [bug-mailutils] Merging libraries (was Re: Mailutils 0.3 released), Sergey Poznyakoff, 2003/02/19
- Re: [bug-mailutils] Merging libraries (was Re: Mailutils 0.3 released), Alain Magloire, 2003/02/19
- Message not available
- Re: [bug-mailutils] Merging libraries (was Re: Mailutils 0.3 released), Sergey Poznyakoff, 2003/02/20
- Re: [bug-mailutils] Merging libraries (was Re: Mailutils 0.3, Alain Magloire, 2003/02/20
- Re: [bug-mailutils] Merging libraries (was Re: Mailutils 0.3, Alain Magloire, 2003/02/24
- Message not available
- Re: [bug-mailutils] Merging libraries, Sergey Poznyakoff, 2003/02/25
- Message not available
- Re: [bug-mailutils] Merging libraries (was Re: Mailutils 0.3, Sergey Poznyakoff, 2003/02/25
- Re: [bug-mailutils] Merging libraries (was Re: Mailutils 0.3,
Alain Magloire <=