W3C home > Mailing lists > Public > www-talk@w3.org > May to June 1995

Re: Agent-mediated access (was Re: Criticism of Kidcode...)

From: Peter Deutsch <peterd@bunyip.com>
Date: Wed, 21 Jun 1995 15:46:30 -0400
Message-Id: <9506211946.AA13329@expresso.bunyip.com>
To: "Marc Salomon" <marc@matahari.ckm.ucsf.edu>, www-talk@www10.w3.org
Cc: rating@junction.net, uri@bunyip.com
[ Marc Salomon wrote: ]
.  .  . 
} Until the uri group bakes URC's that can be accessed and scanned for keywords
} and other metainfo, content filtering can be better handled on the client side
} without munging the protocol and access methods.  Stop-gap measures could be to
} create a list of 'bad words' that the client can grep for in each HTML document
} (an argument for text/html?) or hostname part of each URL and refuse to present
} any offending documents.

This raises an issues with the current crop of
Mosaic/Netscape browserss that we've been struggling with
throughout our project. The currently available APIs to
the browsers seem to assume everything pointed to by a URL
is a file, and the appropriate thing to do with each one
is to render it.  This is a very limiting world view.
We're moving towards a world where it wont just be humans
using these things and we wont want to see just files.
Forcing people to work through the GUI (selecting URLs to
fetch, for example) is going to be way too limiting for
the long run.

I'd like to be able to hand my browser a URL and say "fetch
this for me". I want to get back a data stream (not just a
file) which I could filter and munge to my heart's
content. I'd also like to be able to hand such a data
stream back to my browser with instructions to render,
store, play or whatever. If we go this route, building
suitable filters (whether they be for censorship or
context filtering) would be a whole lot easier, as would
building companion tools which operate above the protocol
level and need to cooperate with the browser. As it is, we
have found ourselves reproducing code that already exists
(eg. the multi-protocol access library) since it's not
currently reachable through the API.

Any takers for API extensions among the client developers?

					- peterd


  ...there is reason to hope that the machines will use us kindly, for
  their existance will be in a great measure dependent on ours; they will
  rule us with a rod of iron, but they will not eat us...

                                               - Samuel Butler, 1872
Received on Wednesday, 21 June 1995 15:48:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:21 UTC