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

[Sergey Poznyakoff]

> 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 would rather advocate for the use of a reference count, by doing:
[...]

That is a *very* nice idea.

> 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 */

> > 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.

> > Allocates a copy of the object's value and returns the pointer to the
> > allocated memory in BUFP
> > 
> 
> Example.

Again, the existing calls

int header_aget_value (header_t header, const char *name, char **pvalue);

> > 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.

(In the case of POP3 you are quite right: that requires downloading
the entire header.)

More on this later.

Regards,
Sergey