Re: Please review new Perl 5 Module List

Gisle.Aas@nr.no
Fri, 24 Feb 95 17:10:14 +0100 

I just requested subscription on the libwww-perl list today. Hopefully
I will start getting mail back from it soon.

The latest version of my library can be obtained from:

      http://www.nr.no/home/aas/WWW.tar.gz

The `lrequest' and `stat' routines actually work.  Things also work
better when the passed $header og $content are undef.  I have
implemented a WWW::Mailto module and added some documentation.  The
mailcap stuff has been merged into the WWW::MIME module.


m.koster@nexor.co.uk writes:
> > If so we can get back to talking design :-)

That's what I want too, so here we go.

> First of all a compliment; it's nice to see movement on this, and see
> more of the original library supported then I had time to do. I do
> agree with Roy that comments in the code are very important, and would
> ask for them to return.

I don't really like the comments to fill more space than the actual
code.  With proper documentation (pods included in the module files)
the need for that much comments should go away, but I take your point.
Some of the comments will come back.


> One thing I dislike is the exporting of so much into the user name
> space (e.g. the RC_* constants). The Perl5 Module List suggests using
> EXPORTS_OK instead of EXPORTS, I'd even quite happily use complete
> name space specifications (WWW::WC_OK) myself and not export
> anything. In my library I kept the error messages in an array, which
> is probably slower, but keeps the names more together (but I'm not
> fussed).

I agree, but why is WC_* better than RC_*?  What does WC stand for?
This might be ugly if the module eventually will be called WWW::WWW.

> I do miss some of the higher level error management functions I have,
> for example to translate codes to mnemonics (and error messages).

Do you mean callbacks or some functions to do:

  $WWW::RespMessage{WWW::RC_SOMETHING}

stuff.

> I'm not sure about the 'tie' interface to MIME::Header and URL
> though.

I am not sure either.  It was just a clever thought.


> With a tied MIME::Header I miss FIRSTKEY/NEXTKEY (to enumerate all
> headers), and end up using the object as a hash itself anyway.

That would be easy to implement.

>                                                               With
> the URL I'd prefer using $url->scheme to $url->FETCH(SCHEME). Maybe
> I've been programming C++ too long, but I think an OO approach looks
> more obvious than opaque hashes, and I don't think it buys you
> anything. This is a farily major point interface-wise :-)

But then we would need two methods for each attribute:

   $scheme = $url->get_scheme;
and
   $url->set_scheme($scheme);


> Some buglets: When using file://, set_fileheader ends up with an undef
> content-encoding in the header. It's be nice for file:/// to default
> to localhost. request_failed() should probably convert $content to
> html (> -> < for completeness. And I'd really like references to
> scalars to indicate this in their name, ie, $contentref instead of
> $content.

Some of this is better in the new version.


> Have you given any thought to allow for chunk-reading callbacks? I
> think they can be quite important from a memory usage point of view,
> and to be able to reset timeouts as bits of data trickle in (important
> on slower lines like mine). Passing the call-back in is easy enough,
> but I haven't thought about the impact on other protocols yet (this
> may not be supported by all protocols).

Callbacks is one possibility.  Getting or returning the content in
files is another one.

I am thinking about change in the WWW::request interface, because I am
not sure it is a good idea to use the same parameter both for passing
and returning arguments.  Using the same parameter makes it more
difficult if you want to pass the same headers or content to
subsequent requests.  The downside is that the parameter list gets
longer.  I suggest to change the interface to this:

  WWW::request $method, $url, $headIn,  $contentIn,
                              $headOut, $contentOut, $timeout;

where $headIn and $headOut are references to MIME::Header objects or
undef if you don't want them.

For the $content parameter I would like 3 opportunities to exist:

    1) pass a string
    2) pass a file name (content found in (or written to) this file)
    3) pass a callback routine

These can be differentiated by these rules:

  - if it is a reference to a scalar then the scalar is treated as a
    string. (ref($content) eq SCALAR)

  - if it is a scalar (not containing a newline) then it is treated as
    a filename.  (!ref($content))

  - if it is a reference to a sub then it is treated as a callback
    (ref($content) eq CODE)

What do you think about this??

Regards,
Gisle Aas.