On Sat, Dec 22, 2001 at 10:37:59PM +0100, Lars Weber wrote: > Adam Olsen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED]
msg01496/pgp00000.pgp
Description: PGP signature
