Front page | perl.pep |
Postings from August 2016
August 8, 2016 21:41
Message ID: 201608082341.05322@pali
On Wednesday 03 August 2016 00:36:11 Ricardo Signes wrote:
> * firstname.lastname@example.org [2016-08-02T17:03:07]
> > I can imagine, that people could be confused about header_str
> > meaning. It has suffix _str and I would expect it needs (Unicode)
> > string, not object... Name "header" is better as it does not say
> > it needs string.
> People will want to be able to pass non-ASCII strings in as subject,
> meaning that header is not suitable for the "one true list of
> fields." Passing in a pre-encoded value is pretty sure to be the
> exception, not the rule.
> In other words, I think this would be more sensible:
> header_str => [
> Foo => raw_mime($header_raw),
> Bar => "Text string to be encoded",
> Baz => $message_id_object,
> The alternative, using header, is:
> header => [
> Foo => $header_raw,
> Bar => mime_encode("Text string to be encoded"),
> Baz => $message_id_object,
Here we are need to deal with objects which internally needs to be MIME
encoded and objects which mustn't.
Image: I have $address object which phrase is already MIME encoded and I
want to pass it into Cc header.
So I would suggest to use header => [...] syntax only for 7bit strings
or object with 7bit strings (e.g. when caller is responsible for
encoding all strings or object strings into 7bit MIME). And syntax
header_str => [...] for Unicode strings (or objects which have Unicode
Which means: if I pass $address object into "header", then phrase of
$address must be already MIME encoded (or ASCII only) and when I pass it
into "header_str" then it will be automatically MIME encoded.
It is OK?
> > And there is another problem still not solved. From $email object
> > it is needed also to read From/To/Cc headers and user (caller) of
> > Email::MIME module is sometimes interested in de-composited
> > addresses objects (e.g. when want to parse each email address in
> > CC field) and sometimes interested only in one string
> > representation (e.g. want to write header to STDOUT)...
> > With explicit $email->header_str() $email->header_addr() and also
> > $email->header_grps() calls user get type which wants. I cannot
> > imagine without 3 different calls how to achieve it.
> Here is the first idea that comes to mind:
> ->header_str always returns a text string.
> ->header_raw always returns a byte string.
> Pardon the arbitrary name, but:
> Read only, always returns an object that can ->as_mime_string. For
> fields that were set without an object, it returns an unstructured
> just-in-time proxy. Headers set with "raw" return the same kind of
> object I proposed above for passing a raw header into header_str.
> Headers set with header_str get the kind of thing that mime_encode()
> returns. Possibly/probably if you have set the From header with
> header_str, you get the object currently being produced, just for
> brief use, in Email::MIME::Encode.
If I create Email::MIME object from input string, I would like to get:
1) Raw (ASCII) string representation of To: field
2) Unicode string representation of To: field
3) List of Email::Address::XS objects which are in To: field
4) List of named groups with Email::Address::XS objects of To: field
For 1) and 2) I can use ->header_raw and ->header_str methods. For 3)
and 4) are needed new method(s). Ideally if caller is able to get
original MIME encoded objects (where in ->phrase part of address object
is still MIME encoded) and also if objects strings are Unicode.
Any idea for 3) and 4)? Note that caller should be able to get list of
those objects (maybe as one object?) of arbitrary header name. Not only
for some hardcoded. As there are new headers like Original-From which
> > But if you still prefer that there should be only one function
> > which accept both objects and strings, lets define its name, how
> > should it act on different types of strings + header names. And
> > also how user of Email::MIME can receive for arbitrary header
> > Unicode string value...
> I believe I'm happy with my suggestion above that both header and
> header_str can work with objects, with the difference being the
> behavior on plain old strings.
I can accept that both "header" and "header_str" will work with objects,
but I think that my suggestion about do not encoding "phrase" string
part of object passed to "header" is useful...
> I realize I have expanded it in the course of this email. Do you
> think it is unworkable in some way?
I think once we solve problem how to get objects from email which is
created from string (or file), it can be usable...