Re: Hurd Projects

[Jeroen Dekkers]

On Sat, Dec 22, 2001 at 10:37:59PM +0100, Lars Weber wrote:
> Adam Olsen <rhamph@d2dc.net> wrote:
> > I agree that seperating the httpfs translator and the caching
> > mechanism would be worthwhile.  But why not just use an existing
> > caching proxy such as squid?  Is there some specific functionality
> > you'd want it to have?  A caching proxy would have to speak http
> > anyway, not fs, and translating between them is what the httpfs is
> > for.
> 
> But it wouldn't than be possible (without further hacks) to show the
> contents of the cache directly in the http directory.  And my idea
> actually was that the cachefs-translator would *not* need to speak http,
> as otherwise it would again only be useful for http-translators.
> 
> What I originally had in mind was this:
> 
>   a) one translator (cachefs, though expirefs might fit better) sits on
>   some node and behaves like a traditional directory except that it has
>   some mechanism for expiring files based on certain configurable factors
>   (like age).
> 
>   b) another translator (ftpfs/httpfs/whateverfs) sits on top of the other
>   translator and simply does what it does best (like fetching files from
>   an ftp-server) without caring about anything else (like caching).

What I have in mind in actually something different. I think making a
cache library providing all caching functions and link ftpfs, httpfs,
etc. with that library is a better way. I haven't really thought about
the solutions of all your problems yet (it's late and I'm going to sleep
soon), but I think it at least solves some of them.

> One remaining question now is whether all this is worth it, or whether a
> traditional proxy wouldn't just do the job as well?  But especially when
> considering things like httpfs as an extension to the development platform
> itself (e.g. something to base a web-browser on), being able to list the
> contents of the cache inside of the directory used for access can really
> make a difference I think.  (Which would still leave us with the option of
> using a http translator with an integrated cache (or maybe integrated
> access to an external cache :))).

Yes, it is. You have different kinds of caches. One kind is the thing
squid is written for: a proxy server used by a lot of clients, most of
the time of the same ISPs or a company's own proxy server. This caches
the requests of different users. The other kind is the thing all
browsers implement again and could be implemented with a translator: the
caching for just one client, on the client's computer. This is useful if
you press the back button for example.

Just think about apt downloading debian packages as an example (that
would probably need other rules than normal files). When I'm doing an
upgrade, apt asks the httpfs translator for the package. If I had
already downloaded the package, the httpfs just provides the package
without any net activity. If I haven't, the httpfs translator would
contact my ISPs proxy server to ask for the package. If somebody with
the same ISP already downloaded the package and the proxy server still
has it, it's able to send the package without adding extra load to the
debian mirrors. If it isn't, only then it would contact the debian
mirror.

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects.net

pgp1YO46UJpC9.pgp
Description: PGP signature