Re: Perl 5 Classes for the Web (CGI and libwww)
Tim Bunce (Tim.Bunce@ig.co.uk)
Wed, 15 Mar 1995 14:51:56 +0000
> From: "Roy T. Fielding" <fielding@avron.ics.uci.edu>
>
> > I think WWW::* is getting rather crowded with WWW::HTTP::*
> > WWW::HTML::*, WWW::URL::*, plus, of course all the other WWW::*'s
> > and it's only going to get worse.
> >
> > I'd strongly recommend using top-level names for the implementation of
> > IETF standards-based objects:
> >
> > URL::* Base, Proxy
> > HTTP::* Base, Header, Error, Date, Protocol, MIME
> > HTML::* ... ? (bound to be lots eventually!)
> >
> > and use WWW::*
> > for any non-standards based objects and assorted support code.
> >
> > Using WWW:: for everything made more sense in the early days but over
> > the next few months and years the WWW:: 'tree' is bound to fill up with
> > assorted 'goodies' contributed by many budding perl programmers.
> >
> > This reorganisation creates much more room in the namespace and
> > emphasises the important distinction between standards-based objects
> > and other code.
>
> Ummm, speaking as a standards person, none of the above are standards.
> In fact, there are some aspects of IETF's UR* which should never be
> implemented (and will be discarded by the IETF at the appropriate time).
> But that's just an aside.
>
Understood. I was using the term loosly. Perhaps "well defined by RFC's"
would be more appropriate. And by "well defined" I mean 'better than
someones idea of a handy collection of functions'.
On the UR* side, I've been tempted to discuss URI/URN/URL issues
and class names etc but I think we'll get a lot of mileage out of
the URL class that Martijn Koster is working on.
> There is a very clear design difference between a Web client and an
> HTTP server. A client does not want the same stuff that a server needs,
> and vice versa. Similarly, there is a very clear difference between a
> newsreader (NNTP client) and a Web client with an interface to NNTP.
> Things which are of interest to clients, servers, CGI, etc. include:
>
> URL::* Base, Proxy
> HTML::* HTML parser, extractor, searcher
> MIME::* media type and mailcap handling
>
> and thus it is reasonable (and appropriate) to make them separate classes.
>
Agreed. (I forgot to include CGI::* in that list, so also throw that in.)
> However, it is neither reasonable nor appropriate to make base classes
> of the protocols unless you also require:
>
> a) They all share a common interface to the invoking program
> b) They all allow the client-side code to be separated from the
> server-side code.
>
> Since that cannot be done in practice, it is reasonable to have
>
> WWW::http
> WWW::ftp
> WWW::gopher
> WWW::wais
> WWW::nntp
> WWW::news
>
> These interfaces may use some other base class to do the real work --
> their purpose is to provide a consistant client interface, just as the
> real WWW does, to those other protocols.
>
That's an good point. Otherwise it would be better to have
FTP::WWW, WAIS::WWW etc. It may be a WWW::wais class, for example,
acts as a 'thin' interface layer for some other WAIS::... classes.
> The perl4 libwww-perl is only a client-side library, though it does
> contain some code that could be used by both (namely, the URL and MIME
> stuff). If you are going to put both client and server code under the
> same tree, you must include some way for the invoking program to choose
> between the two code sets (last time I checked, perl5 didn't have conditional
> compilation ;-).
>
Another good reason for having multiple FOO::* rather than a single
WWW::FOO. Applications only need 'use' the modules they require.
I'm going to post a separate message summarising a proposed set of
module names. We can all kick that around for awhile.
> ......Roy Fielding ICS Grad Student, University of California, Irvine USA
> <fielding@ics.uci.edu>
>
Regards,
Tim.