Hi! On 04/16/2008 08:41 PM Derick Rethans wrote: > On Wed, 16 Apr 2008, Tobias Schlitt wrote: >> On 04/16/2008 07:49 PM Derick Rethans wrote:
>>> The problem of having a dedicated storage stack is that the >>> application then needs to start caring about in which storage stack >>> to store a specific file. I think you might be missing that I meant >>> that in the same storage for cache items, *some* of the items are >>> going to be too big. For example you're storing generated PDFs where >>> most of them are 100kb and a few others 10MB. Here you might not >>> want the complexity of having the application itself do this check >>> as it might complicate the application too much. >> I see your problem. However, you should not cache PDF files in memory >> anyway, but store them somewhere as PDF files and link to them. >> Reading a 100 MB PDF through PHP is overhead in itself, so you would >> not want to use Cache here anyway. > That's just your opinion on this, and perhaps there's other content for > which this does make sense. I don't think so. It's commen sense in the PHP world to store such ammounts of pseudo-static data on disc and let the webserver do what he does best: Serve content. Even starting PHP in this case does not make sense, since it slows down the whole process significantly. >>> I don't see how it is impossible to figure out the size of the data >>> to store btw. >> I do not see any possibility to determine the size of a PHP variables >> content, without writing it to disc. > Well, you can after serialization just before you put it to > disk/memory/whatever. This is only done in userland for the file storages. All other storages leave serialization to the utilized extension. In general I do not consider it a good idea to introduce such features. It unnecessarily raises complexity and therefore reduces performance and maintainability. If you want to "cache" 100 MB PDF files you should either use a dedicated storage for them or store them on disc or let them be cache in memory. I do not see a real use case, where users cannot work around this much more efficient than we would do it in a general component. And basically Cache is all about performance. Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
