Re: libwww, a different approach
Graham Barr (bodg@tiuk.ti.com)
Wed, 15 Mar 95 11:38:28 GMT
In <9503150317.aa26290@paris.ics.uci.edu>
On Wed, 15 Mar 1995 03:17:50 -0800
Roy T. Fielding <fielding@avron.ICS.UCI.EDU> writes:
> [...]
> >
> > Current Inheritance tree
> > ========================
> >
> > WWW::Scheme
> > |
> > WWW::URL
> > |
> > +----------+------+----+
> > | | |
> > WWW::file WWW::mailto | WWW::Proxy
> > | |
> > +---------+-------+--+---+-----+
> > | | | |
> > WWW::url WWW::http WWW::ftp WWW::telnet
>
> Very interesting -- I've never considered separating proxyable from
> non-proxyable. Actually, come to think of it, there is no reason that
> distinction should be made -- a local proxy is capable of proxying both
> file and mailto (the latter as a request->returned form->POST).
What this is saying not that file and mailto cannot be proxied but file and
mailto URLs cannot be used as proxy URLs.
When you proxy somethig you did it with an environment variable like
http_prony=http://www.proxy/
ftp_proxy=http://www.proxy
What my scheme allows is
ftp_proxy=ftp://ftp.proxy
telnet_proxy=telnet://telnet.proxy
IE not all proxies have to be proxied to http:
This is required for people like me who sit behind firewalls and to telnet
out I have to do a proxy telnet to a get machine.
The same goes for ftp, although that could be proxied via http
> > The interface required by each scheme is
> >
> > ->parse($url) parse the URL into segments
> > ->stringify reconstruct the URL
> > ->GET($object, ...)
> > ->PUT($object, ...)
> > etc The methods are called on the server object and the requested
> > object passed as the first parameter. They will be the same if
> > proxy-ing is not being performed.
> >
> > How it works
> > ============
> >
> > A new URL is created by
> >
> > WWW::URL->new('ftp://ftp.ti.com/pub/');
> >
> > WWW::URL->new extracts the scheme from this url and calls the WWW::Scheme
> > method ->scheme to set the scheme. This setting involves locating the package
> > WWW::scheme (eg WWW::http), blessing the object into this package and calling
> > the method parse.
> >
> > Each package is responsible for parsing its own url as there is no generic
> > format for a url (eq mailto:bodg@tiuk.ti.com and http://....). Each package
> > ,for the same reasons, is also responsible for stringifying the url.
>
> Hmmmmm...I'll contest that. It is okay (in fact, necessary) to have a
> generic URL parser -- the schemes just have to know how to stringify the
> appropriate parts prior to a request. BTW, where do you put the resolver
> for relative -> absolute URLs?
That is done inside the parser. This allows each scheme to handle its
own path's as NOT all schemes have identical syntax !!! :-(
> > The user then call methods on this object to retreive/send the object.
> >
> > the user interface functions (get,put etc) call the method proxy which returns
> > a WWW::URL object to represent the server to connect to and scheme to use.
> > This could be the same URL as the object. the appropriate method (GET,PUT etc)
> > is then called on the server object passing the object as the first argument.
> >
> > The main advantage I found is that if an unknown scheme it specified it
> > is blessed into the package WWW::url. This package does not define any methods
> > except parse and stringify but it does allow for any currently unknown scheme
> > to be proxied via a different scheme (eq http)
>
> That is what I would expect Scheme to do.
>
> > The methods GET PUT etc create a MIME message and set the content and response
> > via methods ->content and ->status. Then return the contents or undef.
>
> A MIME message? What does this mean for protocols that don't use MIME
> messages?
A dummy MIME message is created and the content put into the body. I felt that
this was essential to make the return value from each scheme identical as
the calling function may not know which scheme it just invoked
> > If people are interested in seeing what I have done then I will put it on a
> > ftp site
>
> Please do -- the more examples, the better. I could also put it in the
> libwww-perl contrib directory if you are short on space/accessability.
OK where should I put it, I do not have a local publc FTP site
Regards,
Graham.
--
.-----------------------------------------------------------.
//// | Graham Barr Email: bodg@tiuk.ti.com | \\\\
| 00 | VLSI Cell Designer or: bodg@ti.com | 00 |
O ^ | MOS Design TI MSG: BODG | ^ O
\ ~/ | Texas Instruments Ltd Phone: +44 (0)1234 22 3419 | \~ /
| ENGLAND Fax: +44 (0)1234 22 3331 |
`-----------------------------------------------------------'