Re: mailutils (rfc822 parser)

[Alain Magloire]

> 
> I've a patch that addresses most of the stuff we talked about,
> everything but the return codes, better memory management, and
> a test suite to root out leaks. Also incorporated your patch.
> 
> Also, parsing rfc822 header fields, dates, and received lines
> is TBD, if useful. First I'll get the address stuff right.

- Dates are probably a good thing that can be of good use for
other clients like imap4d etc ..

- Header fields as part of <parse822.h> ok,  to merge it to
header.[ch] is a little more complex, since the object
header_t let the concrete mailboxes overload the functions, for
example:
{
  mailbox_t mbox;
  message_t msg;
  header_t header;
  char buffer[64];

  mailbox_create (&mbox, "pop://localhost");
  mailbox_get_message (mbox, 4, &msg);
  message_get_header (msg, &header);
  
  header_get_value (header, "Subject", buffer, sizeof (buffer), NULL);
...
}

header_get_value() function will map to 

TOP 4 0

for POP server. If the URL was "imap://localhost" it would
have map to:

tag FETCH 4 BODY.PEEK[HEADER.FIELDS (Subject)]

- Parsing the receiving lines would be cool but probably not a
high priority since no current programs care about it, perhaps
the sieve stuff.

> It's a lot of textual changes, and I retabbed to a 2char shift
> width, and an 8char tab. It's a big diff, do you want a diff,
> or the whole file? I guess I can just send both, and you can
> choose.

That would be nice, send the entire thing since the diff
would be as large if not larger, I will commited.  I would like
to have this to change message.c(message_t) to use parse822.h

> Also, return codes. The ones I've seen have mostly been:
> 
> 0 - success
> +'ve - an error number

Yes this is our standard 
0 ==> success
0 != failed.

> What should I do, the possible return codes are:
>   . no mem (ENOMEM)
>   . function called incurrectly (EINVAL)
>   . invalid rfc822 syntax found (?????)

ENOENT ?

>   . success (0)
>   . success (with a count for how many successes)

I do not see how  this is usefull, you pass a string to be parse
if it fails for xx reasons, it does not matter how far the
parsing went the address is invalid.  The rest of the functions
is to get info _get_comment(), _get_email(), _get_personal() etc ...
You have them or don't.

> In the absence of precedent, I'd go for >= 0 being some
> variety of success, with 0 being the success value in
> the absence of a count, and -ve being an errno.

I would advocate 0 == success != 0 failure.  This important
in a threading environment.

> Should, instead, I add a reference argument, where the return
> number can go, so that return values are 0 (ok) or a +ve
> error number?

Getting the errno number by having it return from the function
calls can make things easier, in a threaded program.

> And what errno should I use to report on rfc822 parsing errors?
> I like to use system errnos for my apis, too, since it means
> I don't have to map the system error numbers to my own scheme,
> but sometimes it means you have to grap a strange one. I figure
> ENOENT isn't so bad, its unambiguous (for the parseing functions),
> and even vaguely related. I could also define my own, EPARSE,
> and maybe define it to be ENOENT (so it doesn't collide with
> anything).

Sounds good,  I had this discussion already, maybe it did not
spill on the list.  The proposition was to define our
set of error numbers and function calls; mu_strerror() etc ..
We decide not to go this route for now, maybe later, if there
is a real need for it.

> Oh, and where should "parse822.h" go? It might be
> in the public <mailutils/parse822.h>, but wherever's
> useful to you.

include/mailtutils/parse822.h, it will be part
of the default headers to be install:
$prefix/include/mailutils/parse822.h

We've agreed. that parse822 by itself could be very
usefull, altought it is use as the underlying engine of address_t.

> Gotta run, a friend's making me dinner, and love to have people
> cook for me!

8-).  I'm a very good cook  .. when camping.  I can make the most
at of the least, you should taste my "cassoulet" dish .. 
you probably do not want to know the ingredients though ;)

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!