Quantcast

headers everywhere

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

headers everywhere

R. David Murray
I just posted a new blog post:

    http://www.bitdance.com/blog/2011/05/02_01_Email6_Headers_Everywhere/

This describes the work I did two weeks ago on the Headers-as-string-objects
idea we talked about here a couple months ago.  (Last week, as I mention
in the blog post, I was otherwise tied up and got no email6 coding done :(

If anyone has time to read it and give feedback on the API decision I'm
outlining there, that would be great :).   I may change my mind about
some things as I implement more, but so far I'm liking the way this
is turning out.

--David
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: headers everywhere

Barry Warsaw
On May 02, 2011, at 12:23 PM, R. David Murray wrote:

>I just posted a new blog post:
>
>    http://www.bitdance.com/blog/2011/05/02_01_Email6_Headers_Everywhere/
>
>This describes the work I did two weeks ago on the Headers-as-string-objects
>idea we talked about here a couple months ago.  (Last week, as I mention
>in the blog post, I was otherwise tied up and got no email6 coding done :(
>
>If anyone has time to read it and give feedback on the API decision I'm
>outlining there, that would be great :).   I may change my mind about
>some things as I implement more, but so far I'm liking the way this
>is turning out.
Very interesting, thanks for the post!  Although I haven't played with your
branch yet, the API looks pretty reasonable to me.  I'm interested to see how
your dynamic header classes feature works out.  Mailman has its own Message
subclass and I agree that a traditional class-based hierarchy makes using this
kind of a pain.

-Barry

_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: headers everywhere

菊地時夫
In reply to this post by R. David Murray
(11/05/03 1:23), R. David Murray wrote:
> I just posted a new blog post:
>
>      http://www.bitdance.com/blog/2011/05/02_01_Email6_Headers_Everywhere/

Hi David,

Good work.  One point, =?utf-8?q?c2VrcmV0IGMwZGU=?= should be
=?utf-8?b?c2VrcmV0IGMwZGU=?=.  'q' is for 'quoted-printable' and not
'base64'.

Cheers,

--
Tokio Kikuchi, [hidden email]
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: headers everywhere

R. David Murray
On Tue, 03 May 2011 10:01:33 +0900, =?UTF-8?B?6I+K5Zyw5pmC5aSr?= <[hidden email]> wrote:

> (11/05/03 1:23), R. David Murray wrote:
> > I just posted a new blog post:
> >
> >      http://www.bitdance.com/blog/2011/05/02_01_Email6_Headers_Everywhere/
>
> Hi David,
>
> Good work.  One point, =?utf-8?q?c2VrcmV0IGMwZGU=?= should be
> =?utf-8?b?c2VrcmV0IGMwZGU=?=.  'q' is for 'quoted-printable' and not
> 'base64'.

Heh.  Thanks.  Probably if I tried to run the doctests I'd find
other bugs :(

--David
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: headers everywhere

R. David Murray
In reply to this post by R. David Murray
On Sat, 14 May 2011 15:19:42 -0700, Glenn Linderman <[hidden email]> wrote:

> Looks great, conceptually.  My only quibble is with the names  
> .source_value and .decoded: the names are clear, but lengthy (in
> combination with stuff before the .).  Other possibilities:
>
> .source_value:  .orig .src .wf (wire format)
>
> .decoded: .value .dec .r (readable)
>
> On the other hand, it is only a quibble: I'm likely to only use this API
> with email6 policies.

In a previous iteration of the API 'decoded' was indeed 'value', but I
seem to have lost sight of that in the forest of the implementation :).

On the other hand, source_value is the best description I could come up
with.  I started out with 'raw', but it isn't.  It isn't 'wire format'
for the same reason:  it could come from either a bytes/wire format
input, or from a unicode input.  I'd be fine with 'orig', 'source' or
'src', and I don't really care what it is.  The only code that should be
accessing that attribute in the normal course of business is a generator.
Feel free to bikeshed about it :)

I will rename 'decoded' to 'value'.

--
R. David Murray           http://www.bitdance.com
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: headers everywhere

Glenn Linderman-3
On 5/16/2011 1:24 PM, R. David Murray wrote:
On Sat, 14 May 2011 15:19:42 -0700, Glenn Linderman [hidden email] wrote:
Looks great, conceptually.  My only quibble is with the names  
.source_value and .decoded: the names are clear, but lengthy (in 
combination with stuff before the .).  Other possibilities:

.source_value:  .orig .src .wf (wire format)

.decoded: .value .dec .r (readable)

On the other hand, it is only a quibble: I'm likely to only use this API 
with email6 policies.
In a previous iteration of the API 'decoded' was indeed 'value', but I
seem to have lost sight of that in the forest of the implementation :).

On the other hand, source_value is the best description I could come up
with.  I started out with 'raw', but it isn't.  It isn't 'wire format'
for the same reason:  it could come from either a bytes/wire format
input, or from a unicode input.  I'd be fine with 'orig', 'source' or
'src', and I don't really care what it is.  The only code that should be
accessing that attribute in the normal course of business is a generator.
Feel free to bikeshed about it :)

I will rename 'decoded' to 'value'.

Given than, 'orig' or 'src' bubble to the top of my list of preferences.

Seems like in modes with mixed email library versions, these are recommended for regular use, possibly beyond generators, so that's why their length stuck out to me as a possible issue.

_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: headers everywhere

Oleg Broytman
In reply to this post by R. David Murray
On Mon, May 16, 2011 at 04:24:21PM -0400, R. David Murray wrote:
> I'd be fine with 'orig', 'source' or
> 'src', and I don't really care what it is.
[skip]
> I will rename 'decoded' to 'value'.

   My votes are for 'source' and 'value'.

Oleg.
--
     Oleg Broytman            http://phdru.name/            [hidden email]
           Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: headers everywhere

Barry Warsaw
On May 17, 2011, at 12:52 AM, Oleg Broytman wrote:

>On Mon, May 16, 2011 at 04:24:21PM -0400, R. David Murray wrote:
>> I'd be fine with 'orig', 'source' or
>> 'src', and I don't really care what it is.
>[skip]
>> I will rename 'decoded' to 'value'.
>
>   My votes are for 'source' and 'value'.

+1

-Barry

_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: headers everywhere

R. David Murray
In reply to this post by Glenn Linderman-3
On Mon, 16 May 2011 13:31:47 -0700, Glenn Linderman <[hidden email]> wrote:
> Given than, 'orig' or 'src' bubble to the top of my list of preferences.

Given the votes so far and my own preference, I think I'll go with
'source'.  I don't think saving a few characters is worth it.

> Seems like in modes with mixed email library versions, these are
> recommended for regular use, possibly beyond generators, so that's why
> their length stuck out to me as a possible issue.

I think the only library code that would use it would be library code
doing a generator-like function.  I don't expect there to be many
(any?) of those whose use-cases aren't covered by the standard
generators.  Value, on the other hand, will get used a lot.

--
R. David Murray           http://www.bitdance.com
_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: headers everywhere

Stephen J. Turnbull
R. David Murray writes:

 > Given the votes so far and my own preference, I think I'll go with
 > 'source'.  I don't think saving a few characters is worth it.

Thank you for that!

_______________________________________________
Email-SIG mailing list
[hidden email]
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com
Loading...