W3C home > Mailing lists > Public > www-lib@w3.org > October to December 1998

Re: Cache questions.

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Fri, 20 Nov 1998 16:33:56 -0500
Message-Id: <3.0.5.32.19981120163356.00cf6680@localhost>
To: olga@goliath.eai.com
Cc: www-lib@w3.org, olga@goliath.eai.com
At 14:30 11/20/98 -0600, olga wrote:
>I understand the concepts of w3c design. Cache transparency it an important
>issue. But the set of functions dealing with cache entries are made public.
>Among them meta information update, finding and deleting cached entries and
>so on (why are they public?).

You are absolutely right that they in fact shouldn't be public. The only
reason is that for historic reasons, the cache related filters were put
into another module and in order for these filters to access the cache,
these methods had to be public. The last filter that I added in fact is
local and so doesn't need any public functions.

Do you think it is worth fixing?

>Cached entry validation function is not provided
>though. Validation w/o using a full blown request making mechanism is not
>(If possible at all using public w3c methods. - That is what I am trying
>to figure out). 

Not without a Request object - the closest is the cache filter which in
fact checks to see whether a cached response can be used:

	PUBLIC int HTCacheFilter (HTRequest * request, void * param, int mode)
in
	http://www.w3.org/Library/src/HTFilter.c

>Also it would be very helpful is w3c could provide a function returning an
>open stream handle which would allow operations like:
>stream->ReadBytes(numBytes, buffer), stream->Reset(), stream->Seek(..). 
>Implementing such functionality using w3c streams doesn't seem to be easy.

I have been going back and forth on this for a long time. One of the
important differences between libwww streams and Java streams, say, is that
the former are "push" streams whereas the latter are "pull" streams. That
is, libwww streams are fed data automatically and can't refuse, pull
streams actively read data from the next stream.

There are several reasons for this - first and foremost, push streams fit
better with Internet access where the focus is on max network throughput.
It ensures that data is handled as soon as it is available and not when the
application feels like it.

However, a push stream can easily be converted to a pull stream by using
some memory to buffer the contents. There is already a stream doing
something close to this defined in 

	http://www.w3.org/Library/src/WWWStream.html

and that is the Stream to Chunk Conversion stream. I do actually believe
that the HTChunk class should have methods like seek, get bag of bytes,
etc. defined. I would be very interested if someone (you?) would help
contributing this.

Thanks,

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk
Received on Friday, 20 November 1998 16:34:02 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 17:59:22 EDT