On 2012-06-26 11:18 PM, Jeffrey Honig wrote: > A few points on this discussion: > > 1) The person who promised to re-write the API was an Internet Elder. > Google it.
and after that... bite me. > 2) Callbacks vs data structures > > One reason you might want to have callbacks is that the content > might be GPG or otherwise encrypted and you may want to prompt the > user. You could of course put methods/callbacks in the data structure > to handle this. i think a part handler could read/write from a mime_part_t into a gnupg pipe either way. we may want to offer a recursive iterator that does the callback thing, for callers who prefer working that way. but such callers would have to maintain their own ancestor-state to know which leg of an alternative-multipart they were in, and so on. so it's not obviously easier, just different. > 3) Expanding MIME messages into dirs > > a) Don't forget about encrypted content when using a cache, you > probably don't want to cache it. i agree that you certainly would not want to cache the cleartext. but caching a second copy of the crypted text, where the part it was in got copied to a file somewhere and all the base64 got decoded, is no big deal? > b) If you use .msgnum.mime would most clients ignore the dirs (i.e. > .55.mime)? all the mh directory processors i've written (or in the case of uw imap, that i've patches) ignore dirent's whose name begin with a dot, before they bother to stat() it to see if it's a directory or not. i think we could ignore those who don't. but i still prefer not to permanently unpack mimeballs. the authoritative source of a message is what came in over SMTP, with a received: header added. in fact i'd've been willing to keep the \r\n line terminations, though that ship has already sailed. anything that's non-canonical should be in a separate storage container, such as nmh-cache. paul _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
