|
|
Posted by robert on 05/15/06 23:10
| Hmmmz. This dynamic method is definately more flexible, but requires more
| from the server. It has his advantages, sizes are changed on the spot
| without hassle, there only needs to be one image, not several sizes. It
| could take a lot of processing though. I'd prefer this method as it is
more
| easily maintained, however, when stretched for processing power ot memory,
| and storagespace a plenty, it's the first thing to become statical.
i don't dispute there are opportunities and shortcomings with either method.
i wish martin would flesh out *exactly* the point you just made. my
background plays a big role in that code...and that approach is highly
prized by the companies for whom i work since:
it IS easily maintained
if *flexible*
easily understood
formalized
does not clutter the file system
produces desired results with comprarable server loads as cached
imaging...leaning slightly toward a tad slower.
as i'm sure you understand in the for-pay world, the list above is ordered
by importance (long-term company perspective). projects are made and broken
just by the first three items alone...maintenance and flexibility being the
most important.
| I also don't really see the point of denying caching. Why not give it a
| filename according to size (like 'thumb-h200-w200-'.$imagename), and let
the
| users cache all they want? The images themself aren't changed that often I
| believe...
don't deny it...just deny martin's ability to demonstrate caching in a
manner that would show it as preferable - specifically when making the case
of server load comparasons.
| > then again, i could care less what you recommend as it seems your feet
| > aren't firmly planted in reality and your head doesn't interpret
| > practicality...plus, at the end of the day, only one of us is
| > bringing home a paycheck. ;^)
|
| Now, behave :-).
really rik, i'm truly roflmao with that! thanks...needed the chuckle. ;^)
Navigation:
[Reply to this message]
|