W3C home > Mailing lists > Public > www-jigsaw@w3.org > July to August 1997

Re: Jigsaw's cache mecanism

From: Anselm Baird_Smith <abaird@www43.inria.fr>
Date: Tue, 1 Jul 1997 08:25:05 +0200 (MET DST)
Message-Id: <199707010625.IAA14799@www43.inria.fr>
To: Julianne Freire de Sousa Pepeu <jfsp@di.ufpe.br>
Cc: Yves Lafon <ylafon@w3.org>, www-jigsaw@w3.org
Julianne Freire de Sousa Pepeu writes:
 > > > Since  w3c.www.protocol.http.cache.CacheFilter class doesn't seem to
 > be
 > > > a filter, it cannot work coupled to a resource, does it? In this case,
 > > > why does this class have the ingoingFilter e outgoingFilter methods?
 > > 
 > > It is a filter! But a client-side one, you may also notice an exception 
 > > filter which is used in ProxyDispatcher, for example. (See the "Client 
 > > Side Components" part of the documentation).
 > Ok. I thought it was not a filter since all filters are  defined
 > as a subclass w3c.jigsaw.resources.ResourceFilter as stated in 
 > the filter tutorial.

In some sense you're quite right: the server side of Jigsaw
(w3c.jigsaw.*) is totally independant of the client side
(w3c.www.protocol.http.*). However both of them define some notion of
"filter". I guess you know what they are on the server side; on the
client side they allow you to hook special processing before and after
a request is emitted by some client (that client can be a proxy, a
broswer - HotJava or Amaya, or whatever else). Examples of client side
filters are:
- the cache (as used by the proxy), not to be confused with the server
  side CacheFilter which tries to do in-memory cacheing of most
  heavily accessed documents
- cookies (to be included in next release)
- authentication
- etc (check all subpackages of w3c.www.protocol.http)

 > > > Is it possible to use the proxy coupled if the cache mecanism
 > disabled?
 > > > How to disable it?
 > > 
 > > By default, the proxy doesn't use the cache
 > In case, the proxy use the cache by default. I didn't change the original
 > set up but my Jigsaw/Jigsaw/config/cache diretory is full of cached.*
 > archives.

The default configuration is done in such a way that if you use Jigsaw
as a proxy it will do cacheing (that's the primary reason you would
use a proxy - hence the choice). That default setting is expressed in
the properties.

 > > to use the cache, or ICP, or 
 > > ProxyDipatcher (or any hand-made client-side filter), you should add it 
 > > from the Proxy property sheet, or set directly the 
 > > w3c.www.protocol.http.filters property in the server props file (it is 
 > > better to add the filters via the configuration interface).
 > I tried to do it today but I got the following page:
 > Failed to create and attach filter to target:
 > w3c.www.protocol.http.cache.CacheFilter

Correct: you're trying to use a "client" side filter as a server side
filter (that's the price of using the same name for different things
...). To install a client side filter use the following property:


As in:

(a '|' separated list of client side filter classes)

 > To be clearer, let me explain what I am trying to do with Jigsaw.
 > I'd like to use the ProcessFilter coupled to the proxy. I need to know
 > how to programm it in order to guarantee the caching will be done
 > ONLY after the execution of the content of the ProcessFilter COMMAND
 > attribute. 

I see. The ProcessFilter being a server side filter, it will only
allow you to act on the cached stream. In your situation what you
would have to do is write a client side ProcessFilter (which currently
doesn't exist) and plug it (using above property). Note that the order
in which the filters are declared in the property matters, in your
case you probably want to have:


(process filter will be invoked first, and the cache filter will than
cache the processed stream). 

Received on Tuesday, 1 July 1997 02:25:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:31 UTC