Re: Perl 5 Classes for the Web (CGI and libwww)

Roy T. Fielding (fielding@avron.ICS.UCI.EDU)
Wed, 15 Mar 1995 02:15:06 -0800 

> 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.

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.

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.

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 ;-).


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>