Re: Please review new Perl 5 Module List
Gisle.Aas@nr.no
Tue, 28 Feb 95 16:38:49 +0100
> > content(sub {...})
> > Reads the content in suitable chunks
>
> I suggest adding an optional 'size' argument to indicate the
> size of the chunks to read in.
>
> > and calls sub for each
> > chunk.
>
> along with optionally the length of the data read?
Why do we need this. Can the length be something else than what the
perl function length($data) returns?
> > At EOF it calls sub with undef as argument.
>
> Is that required? You know input has ended when &content returns.
OK.
> What about errors that may occur during the callbacks? &content
> could return an result code of some sort, or even an error message.
> Should WWW::Response change it's internal result code if &content
> failed?
Don't think so. Returning undef on failure and 1 otherwise (like many
perl functions do) should be sufficient. You should be able to take a
look at $! if you get undef.
> I really like this design. Is there anything we've missed out that we
> might regret? It looks like client-side format transformation and
> caching can be added without upsetting the API. I guess interrupts and
> multi-threading might be different, but will probably have to wait
> until Perl supports it anyway... We will need HTML parsing, but that
> should be completely separate. Anything else?
One thought that strikes me is why we don't just provide a perl
interface to the CERN libwww code. Does anybody know the internals of
libwww well enough to comment on how difficult this would be?
--Gisle