Re: Conditional GET in Cache_Lite

> Just to make sure we're clear, when you say HTTP_Request, do you mean > Cache_HTTP_Request, which is a child of Cache, or the HTTP_Request > package? IIRC, Cache_HTTP_Request uses HTTP_Request to get the remote > file and cache automatically. Personally, I think this is something > that should be handled within Cache_Lite itself, not an extension of > Cache_Lite (like Cache_Lite_HTTP_Request or something). I would prefer a lot as a an extension of Cache_Lite like Cache_Lite_HTTP_Request because it's a "PEAR design" and because if we add a lot of things in the core class, it will become too big and perfs will be less good. > > Another way is to make a new class which > > extends Cache_Lite : Cache_Lite_Conditional and redefines the get() > > method. The choice depends on your code. Any advice about it ? > > This is how it's done in Cache, but I would rather see it integrated > directly into Cache_Lite. I think this could go either way, since > things will have to be changed in either case to move it from Cache to > Cache_Lite. I'm ok for a direct integration but only if the code is small. The core class has to stay light and small. Else, we will use an extension. > The other issue that was brought up was what would happen to > Cache_HTTP_Request. I wonder if it would be possible to somehow map > Cache_HTTP_Request's API to Cache_Lite's HTTP features (however we > decide to do it) so that we would only have to maintain one class, but > existing Cache_HTTP_Request implimentations would still work. This > would mean Cache would need a dependency on Cache_Lite, which would be > weird... Cache_Lite and Cache have not same goals and design because Cache is flexibility oriented whereas Cache_Lite is "speed and safe" oriented. That's why there are two Cache classes in PEAR. Maintain one class is a good idea but the need of a dependency on Cache_Lite in Cache is really dirty :( The real solution would be to mix Cache and Cache_Lite on a single new package. But it would be difficult (technical choices are really different...). Fabien MARTY (I will be far away from my linux box until september, 13th)