Re: Email::Address::XS

--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* [email protected] [2016-07-12T11:43:02]
> On Monday 04 July 2016 01:52:41 Ricardo Signes wrote:
> >=20
> > I'd stick to header_str, I think, but I'm not sure.  At any rate:
> > yes.
>=20
> And this is what I do not like... to pass objects to function with name=
=20
> header_str. That name sounds like it takes string, not object (or more=20
> objects)...

Either we can add a new name, so people end up having to give "header_str" =
and
"header_obj" or we can say "in general everything uses header_str, which
follows these simple rules."  I would rather do that.

> > > Still do not know how to handle non-MIME headers correctly in
> > > Email::MIME module. We can either create blacklist of non-MIME
> > > headers and extend it every time when somebody report problem or
> > > create whitelist of MIME headers... Or let caller to decide if his
> > > header must be MIME-encoded or not.
> >=20
> > I'm sorry, I don't understand.  Could you elaborate?
>=20
> If passed pair (header-name, header-value) needs to be MIME encoded or=20
> not. Currently there is blacklist in Email::MIME for header names which=
=20
> are never MIME encoded (like Message-Id, Date, ...) when passing as=20
> header_str.

So, I'd assume we'd go forward with:

* if you know exactly octets you, the user, want in the header field, use
  "header", but this is likely rare
* if you want to provide a string for a field that's pretty much just a str=
ing,
  use header_str and if it requires special handling, we do our best, which
  should get better over time
* but if things are complicated, use an object that represents the structur=
ed
  data

I don't like the idea that this will be broken further by adding the object
behavior, though.

  $email->header_str_set($field =3D> $email->header($field));

=2E..should not break things.

> > "header_str" is "text string" which means it will get encoded.
>=20
> Not exactly, there are exceptions (Message-Id, Date, ...) plus special=20
> behaviour for addresses headers.

Those /mostly/ still get encoded, but we know that the strings are meant to=
 be
structured, so we try to deconstruct them and encode them correctly.
I think those fields that get passed through unchanged are probably in erro=
r at
least insofar as they let you put non-7-bit-clean data in your headers.  Th=
is
should probably be fatal:

  header_str =3D> [ Date =3D> "\N{SMILING FACE WITH HORNS}" ]

> Addresses and groups are really something different as previous types=20
> (strings). And if we threat them as objects, I would rather see e.g.=20
> header_obj (or other different name) instead mixing it again with=20
> header_str (which already have exceptions :-(). This is my initial=20
> reason for header_addr/grps to distinguish it.

My feeling is that Perl programmers are used to polymorphic interfaces, and
that multiplying the number of ways to specify headers is a needless confus=
ion.
What is the benefit to the end user of splitting things up?

--=20
rjbs

--OXfL5xGRrasGEqWY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXn9RyAAoJEOYby6cMccU5djQH/3usc3T9CFyiZSGsIGRP8Hl7
nSLR+NS/ds6GYHvxkWOoQdoGhOLHeWVsxboTvS3d9j2RmOPS7WBjP5SuQhQKluhQ
oRHYDv/VpXRyL4SkEBYH5DOfAymuLGGXcd5azmofYRCKxAYAGWUFrqvxIuZNcK5F
iuCIawZ6ZicR5FXhkNXYwgVFpOJ/bR4z2c9tN78Z6/kzR3OX38rFTPqz7uVPN8Ay
a1lRdvlldnlGs428yXPGlWI9DKLxfmXqcYbnbGOH3AGI9Uj/iaT8DGxx9CyAmyMK
i9l6C2ErkCgCwIeupwWIHPIKADUx4WgfBxJZmc4UCZ7dK/weWdZUxe6EaT/HEQc=
=Owfr
-----END PGP SIGNATURE-----

--OXfL5xGRrasGEqWY--