[Email-SIG] I miss size() (and some latest frustration)

[Steffen Daode Nurpmeso]

On Thu, Mar 24, 2011 at 05:41:49PM -0400, Barry Warsaw wrote:
> On Mar 24, 2011, at 05:10 PM, Steffen Daode Nurpmeso wrote:
> So, I'm not sure whether the email package can have a consistent notion of a
> message's 'size'.

> Do you have suggestions for how the email package can help with these use
> cases?  Do you have specific API or implementation proposals?

An incremental package must of course have a notion of a "current 
state of a message", so that all methods of an object must first 
check wether they're applicable - anyway!? 
Methods which can be used in multiple states need to document how 
they react in each of those anyway (if behaviour changes). 

So that there may be .current_parse_state() returning 
a to-be-defined enum. 
Or size() may return a tuple (Bool_is_final_size, current_size) 
(but that's really ugly). 

Beside size(), the most simple way would be to extend the 
FeedParser so that it could stop in a defined way at all 
boundaries of a message (i.e. Headers,Part,Part...). 
That would be a state(). 
It would need to be restartable, i.e., .close() may remain and 
return an entire message, but .last_part() or so/etc. must be 
added.  .feed() must return something useful, too.  E.g.:

    dataf = SOMERAWDATA.get_fileobject()
    while 1:
        l = dataf.readline()
        ..
        parser_state = fp.feed()
        if parser_state == fp.BOUNDARY_SEEN:
            ..
            break
        ..
    # This is a header object
    # (Or, simply: Message without payload)
    headerobject = fp.get_headers()
    rewrite_headers(headerobject)
    datachunk = prepare_as_sendfile_header_object(headerobject)
    call_sendfile_with_headers_and_unchanged_rest_of_dataf

Interestingly FeedParser has almost all capabilities which are 
required to do all that internally, but it does not offer it to 
the outside.  8-)

Anyway, EMail is capable of many things, but it does not expose 
them to the outside, so that one gets stuck soon if a special task 
is to be performed.  email.message_from_xy() is a fantastic 
abstraction of a complex set of RFC's and real-life potholes. 
On the other hand a programming package is not a shelter - you 
can mess up any package which goes beyond some message_from_xy(). 
So i really think that it is acceptable to offer an interface 
which gives you access to partially constructed objects as long as 
it is well-defined in some manner.

--
Steffen Daode Nurpmeso <sdaoden at gmail.com>
:wq steffen