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

[Alain Magloire]

> 
> > But would also like to notify message_t that it is no longer
> > necessary to hold on to it and free() the memory.  
> > 
> > Your proposition about notification is nice, but how does can it help
> > it the case describe above?
> 
> Both should actually be used together as they complement each other.
> The counter makes sure no extra memory is allocated, and the
> notification mechanism prevents coredumps in a code like:
> 
>       stream_open (&str);
>       message_set_stream (msg, str);
>       /* something gets done ... */
>       stream_destroy (&str);
>       message_get_header (msg, &hdr); /* would coredump here */
> 

Yes understood, in this particular scenario, when doing things like:
        message_set_stream();
        message_set_header();
meaning setting alien/different parts on the message, the message could
put himself has listener/observer of those objects, so when the parts are
destoyed it can be notify and remove the references in its underlying structure.

> 
> > In brief, I want to call say:
> >     message_get_header()
> > xx number of times and would like to have this function lightweith i.e.
> > it does not malloc() each but caches the result.
> 
> Of course! We cannot now require a header_destroy to be called for
> each message_get_header, that would mean rewriting all the
> existing applications.
> 

I do not quite understand the answer, your are saying you do not
want to do this, because it is incompatible to the old way?
So about new functions:
{
  mailbox_t mbox = ..;
  message_t mesg = NULL;
  int i; count = 0;
  mailbox_messages_count(mbox, &count);
  for (i = 0; i < count; i++) {
    mailbox_get_message(mbox, &msg);
    {
       // process the message.
    }
    message_unref(msg);
  }
}

message_unref(), or xxxx_unref() could tail the mailbox implementation
that it no longer needs the object message and it can clear from the cache.
message_destroy() could not *really* wheter or not the refcount is 0.
For example, we already have a message_ref(), this is use in the mime_t
mime.c,  since the mime code does not want the message to suddenly dissapear.

Note, the new destroy notification should clean this for mime.c:mime_t code.


> > > b) Any information retrieving function should have three interfaces:
> > > 
> > 
> > 300% on this, its time to be consistent.
> 
> A minor explanation is in order. Of course I meant those functions
> that return string values, e.g. header_get_value, address_get_email,
> etc.
> 
> > > Stores as much as SIZE-1 bytes of object's value in BUF, adds the
> > > terminal zero. The amount of data actually written is stored in the
> > > memory location pointed to by N, unless it is NULL. If BUF is NULL,
> > > the actual length of the object's value is stored in N.
> > > 
> > 
> > example please.
> 
> Well, currently we have
> 
> int header_get_value (header_t header, const char *name, char *buffer,
>                       size_t buflen, size_t *pn);
> int address_get_personal (address_t addr, size_t no, char *buf, size_t len,
>                           size_t *pn);
> 
> et al. They are used quite often in the code.
> 

Agreed, on this.

> Again, the existing calls
> 
> int header_aget_value (header_t header, const char *name, char **pvalue);
> 

Agreed.

> > > c) The header_t object should be responsible for caching the header
> > > values, not the underlying header implementation.
> > > 
> > 
> > Ok.
> > I do not remember what we do for POP3, but the only way
> > to do this in POP is to download the entire header with TOP.
> 
> Let me explain myself a bit clearer here. The header_t object as
> currently implemented does not provide any means for fast access
> to the headers. Instead, the underlying objects have _get_fvalue
> methods which do this. My opinion is that they should change roles
> here, the underlying implementation (mbox, mh, pop, etc) doing
> the actual work of retrieving the headers, and the header_t
> being responsible for caching.

Ok, with that, sharing code is good, reduce the bloat.