Re: API for Header objects [was: Dropping bytes "support" in json]
"R. David Murray" <[email protected]>
| Newsgroups | gmane.comp.python.mime.devel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 17 Apr 2009 at 13:37, Tony Nelson wrote: > At 19:09 +0900 04/17/2009, Stephen J. Turnbull wrote: >> Tony Nelson writes: >> >> I agree with you that we should make it relatively difficult to put >> things that *don't* conform to the RFCs on the wire. But that should >> be the responsibility of the middleware that talks to the file system >> and to the MTA. I see no reason *at this stage* to burden MUA (in the >> general sense) developers with all the RFC rules, and MDA/MTA writers >> "should" only need to worry about it for error handling (__bytes__() >> should normally do the job for them). (For values of "should" >> equivalent to "in my dreams", I do fear.) > > You are insisting on is so burdening them. I propose lifting that burden. I don't see how Stephen and my proposals burden the developer more than yours. In fact, I'm pretty sure it's the opposite way around. >>> This makes it very important that the easy way of doing things be >>> the correct way. With Address fields, that way is >> >> Nonsense. You are ignoring the fact that *people* (ie, nobody >> participating in this thread<wink>) read an address field *as text*, >> and they type in addresses *as text*. We do not extract and inject >> this information as pickles of Header objects via Firewire sockets >> implanted in their skulls. There is *no /unique/ correct way* here. > > If only "People" did that in a way that survived transport. I don't understand that comment. It's the email package's job to provide a way for the programmer (the user of the email package's API) to allow the text entered by the user (the person actually sending and receiving messages) to survive transport. --David