Re: mailutils (rf822 parser)

[Alain Magloire]

> 
> Quoting Alain Magloire <address@hidden>, who wrote:
> > > is TBD, if useful. First I'll get the address stuff right.
> > 
> > - Header fields as part of <parse822.h> ok,  to merge it to
> > header.[ch] is a little more complex, since the object
> 
> Uh, one of your earlier emails said "uncomment the functions
> that parse headers" that I had left around. Are you now saying
> you don't want to use them? :-) Anyhow, they're hanging about.

8-)
Not at all,  parse822.[ch] can be use standalone.  I will change
message.c and in other places to use parse822(cleaner).

What I meant is:
A place that will be a bit difficult is header.c(header_t):

1-
header_get_value() can be overloaded for a specific
mailbox.  For example, when getting message/header from a
IMAP mailbox, the imap mailbox constructs a header_t for you
but overload the functions so when you do

header_get_value (header, "Subject", buffer, sizeof (buffer), NULL);

This will map to

tag FETCH msgno BODY.PEEK[HEADER>FIELDS (SUBJECT)]

2-
I have to admit that header.c is ugly 8-) and I've always postponed
the rewrite.

3- The idea is to slip underneath header_t parse822.
But when doing this I'll take the opportunity to do (2)(see above 8)

> > - Parsing the receiving lines would be cool but probably not a
> > high priority since no current programs care about it, perhaps
> > the sieve stuff.
> 
> I'm pretty interested in Sieve, probably more interested than
> time allows.

Cool, the more the merrier.  But I hear you, summer is comming fast
the snow is fading away like a bad memory.  I do not see myself
in front of a computer, all summer.

> > > 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.
> 
> Not quite. This is a valid address:
> 
> hi alain: ;
> 
> parse822_group() rightly returns success, but it doesn't create
> and address right now... At a higher level, address_create0(),
> I check this and change the EOK to an EPARSE (<- defined to
> be ENOENT)... not exactly correct. Theirs some other things I
> could do, but it's to late to talk about them now.
> 

Ok.
Suggestion: if its a valid address, why not let the address_create()
succeeds an the calls to address_get_{comment, email, personal}()
return an empty string.

> > > 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 ;)
> 
> I used to eat the rum balls at the coffee shop I worked at for years,
> nobody else could believe it. I figure, after it's cooked, the only
> thing that matters is how it tastes (unless you're paying for it, then
> appearance is important!).
> 
> 
> I just ran my self tests, I parse all the addresses in Addrs (attached)
> identically to before this round of changes, with the exception that
> some addresses that could be parsed as valid up to some point are now
> called bad.
> 
> address@hidden, address@hidden, boot=> pcount 2
> -1 email <address@hidden>
> -   local-part <OSULLIE> domain <rte.ie>
> -2 email <address@hidden>
> -   local-part <skidswam> domain <hotmail.com>
> address@hidden, address@hidden, boot=> pcount 0
> 
> boot is garbage, so I turf the whole thing... what should the approach
> be? Best effort, or "822 or nothing!".

Good question, we'll have to view in terms of someone writing
an email client for the library.  So if you were rewriting elm or pine
what would be the sane behaviour to make the life of the programer easier ...
I do not know.

> address@hidden@dikke.penguin.nl=> pcount 1
> -1 email <address@hidden>
> -   local-part <rfunk> domain <wks.uts.ohio-state.eduofflinemailer-bounce>
> address@hidden@dikke.penguin.nl=> pcount 0
> 
> I call that garbage now, too.
> 
> 
> I'll be away for the weekend, I'll mail you something next week that's
> more tidy, and contains a ChangeLog (but see top of parse822.c).
> 
> Also see attached my test program, is it useful enough to be squirreled
                                                              ^^^^^^^^^^^^

Hey! That's not funny 8)
In any case, jose'phine, left us(snif).
But it's a long story best told in front of a few drinks.

> away in the cvs somewhere? I don't know if I've mailed you it before.

OK, I will do the update shortly tonight.

--
alain