Re: [rfc] HTTP::Multipart
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
Re: [rfc] HTTP::Multipart
Paul Marquess [EMAIL PROTECTED] writes: Does this interface allow you manipulate nested multi-part messages? Yes. The parts() method on HTTP::Message return HTTP::Message objects so there should not be any problem nesting this as you see fit. The MIME::Entity class provide a method called parts_DFS that return all parts in a depth-first-search order. I don't see a need for it for HTTP::Message, and it can easily be constructed from the parts() method. Regards, Gisle
Re: [rfc] HTTP::Multipart
On Sat, 3 Apr 2004, Gisle Aas wrote: Joshua Hoblitt [EMAIL PROTECTED] writes: 1) Is this a good idea? The usecase for this seems a bit unclear to me. How would you use this module? I don't understand what needs handling of multipart responses requires. An example would be handling the response to a request that had multiple 'Ranges' of a resource. 2) Is HTTP::Multipart a good name? I think all that would be needed for this is a method on HTTP::Message. It could for instance be called 'parts'. If the method is not too long and generally useful then it should just go into that module. Sounds reasonable. I'll submit a patch. 5) if a class method is sufficient, would should it's name be? (ie., Cparase?) What does 'parase' mean? It means I tried to type 'parse' before having my morning coffee. :) -J --
Re: [rfc] HTTP::Multipart
Joshua Hoblitt [EMAIL PROTECTED] writes: I've been kicking around the idea for this module for a few days now and I'd like to commit it to code. The module I'm proposing would be called CHTTP::Multipart. It would accept an CHTTP::Response object and determine if it indeed does contain a multipart HTTP message. If it does then the passed object would be cloned once for every part in the message and the 'Content-Length', 'Content-Type', and 'Content-Range' headers would be adjusted along with the Ccontent value to reflect one of the parts. Then a list of non-multipart CHTTP::Response objects would be returned. I believe this would simplify handling multipart responses. 1) Is this a good idea? The usecase for this seems a bit unclear to me. How would you use this module? I don't understand what needs handling of multipart responses requires. 2) Is HTTP::Multipart a good name? I think all that would be needed for this is a method on HTTP::Message. It could for instance be called 'parts'. If the method is not too long and generally useful then it should just go into that module. 3) Is it appropriate to require CHTTP::Response objects? Would just requiring objects to be ISA CHTTP::Message or CHTTP::Headers be better? It is best not to require any specific object at all. Just depend to a certain interface, i.e. a set of methods to be implemented. 4) Should there be an CHTTP::Multipart object that contains a list of modified CHTTP::Response objects or would a class method be sufficient? What you described above appear to be a simple function that takes one HTTP::Response (or HTTP::Message) and breaks it into (possibly) many smaller. I don't see any need for an extra object or class here. 5) if a class method is sufficient, would should it's name be? (ie., Cparase?) What does 'parase' mean? Regards, Gisle
