Does this interface allow you manipulate nested multi-part messages?


From: Gisle Aas [mailto:[EMAIL PROTECTED]
> Thinking some more.  This is what I think I would like to see.
> We introduce the methods 'parent', 'parts' and 'add_part' to
> HTTP::Message.
>   $msg2 = $msg->parent
>     This attribute point back to the parent message.  If defined
>     it makes this message a message part belonging to the parent
>     message.  This attribute is set by the other methods described
>     below.
>     We might consider automatic delegation to the parent, but
>     I'm not sure how useful that would be.
>   @parts = $msg->parts
>     This will return a list of HTTP::Message objects.  If the
>     content-type of $msg is not multipart/* or message/* then this
>     will return the empty list.  The returned message part objects
>     are read only (so that future versions can make it possible to
>     modify the parent by modifying the parts).
>     If the content-type of $msg is message/* then there will only
>     be one part.
>     If the content-type is message/http, then this will return either
>     an HTTP::Request or an HTTP::Response object.
>   $msg->parts( @parts )
>   $msg->parts( [EMAIL PROTECTED] )
>     This will set the content of the message to be the provided list
>     of parts.  If the old content-type is not multipart/* or message/*
>     then it is set to multipart/mixed and other content-* headers are
>     cleared as well.  The part objects now belong to $msg and can not
>     be set to be parts of other messages, but clones can be made part
>     of other messages.  This method will croak if the provided parts
>     are not independent.
>     This method will croak if the content type is message/* and more
>     than one part is provided.
>     The array ref form is provided so that an empty list can be
>     provided without any special cases.
>   $msg->add_part( $part )
>     This will add a part to a message.  If the old content-type is not
>     multipart/* then the old content (together with all content-*
>     headers) will be made part #1 and the content-type made
>     multipart/mixed before the new part is added.
>   $part->clone
>     Will return an independent part object (i.e. the parent
>     attribute will always be cleared).  This ensures that
>     this works:
>         $msg2->parts([map $_->clone, $msg1->parts]);
> When the parts are updated via the parts() or add_part() method, then
> a suitable boundary will be automatically created so that it is unique
> (like HTTP::Request::Common currently does).  If the boundary is set
> explicitly then it is kept and the user is responsible for ensuring
> that the string "--$boundary" does not occur in the content of any
> part.
> The current HTTP::Message object also provide the 'protocol()' method
> that does not make sense for all parts.  This method should be moved
> out or replicated in both HTTP::Request and HTTP::Response.
> Regards,
> Gisle

Reply via email to