Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5827 > unrolled thread
| Started by | Dominique Ottello <air.intakes@fra.fr.invalid> |
|---|---|
| First post | 2012-05-06 11:12 +0200 |
| Last post | 2012-05-08 09:49 +0200 |
| Articles | 20 on this page of 143 — 18 participants |
Back to article view | Back to comp.lang.php
Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 11:12 +0200
Re: Windows binaries 64bit for PHP "J.O. Aho" <user@example.net> - 2012-05-06 11:51 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 17:23 +0200
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-06 18:11 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 19:04 +0200
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-07 20:05 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-07 20:23 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-07 17:16 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-07 16:49 -0500
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-07 15:01 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-07 20:15 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-07 20:37 -0700
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-08 09:11 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-08 08:21 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-08 11:17 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:14 -0400
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-09 17:05 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 12:21 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-09 19:36 +0100
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-09 21:31 +0200
Re: Windows binaries 64bit for PHP Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-05-12 11:12 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 22:56 +0100
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-14 10:51 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-14 10:17 +0100
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-14 19:26 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 00:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:52 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 08:50 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 08:01 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 21:01 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 15:12 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 11:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 06:50 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 13:57 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:29 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-11 13:32 -0500
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 20:01 +0100
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-08 22:25 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-08 21:29 -0500
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 09:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:17 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 16:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 10:38 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 16:54 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 12:23 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-11 13:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 07:38 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-11 15:44 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:30 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-11 13:38 -0500
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-14 10:48 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-09 11:34 -0500
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 11:30 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 15:52 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 13:46 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:10 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 00:19 +0200
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 15:28 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:53 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 13:15 -0700
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-10 21:48 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 17:05 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 14:29 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 19:35 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 18:50 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 22:22 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-11 10:03 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 13:56 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 11:58 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 06:51 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 21:11 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 15:29 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 21:53 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:11 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-12 01:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 20:44 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:38 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:36 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 14:01 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:34 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-11 20:58 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 15:30 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-11 21:46 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:14 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-12 14:42 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 11:04 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-12 18:40 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 15:49 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 22:59 +0100
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-13 13:46 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-13 07:50 -0500
Re: Windows binaries 64bit for PHP Anders Wegge Keller <wegge@wegge.dk> - 2012-05-13 16:15 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 10:36 -0400
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 09:06 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-13 18:54 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 13:27 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-13 22:26 -0500
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 09:51 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 08:04 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 14:25 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 09:37 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 16:22 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 16:45 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:07 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 22:37 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:47 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-14 16:53 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:06 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-14 20:36 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:53 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 23:04 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:48 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 23:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:57 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:38 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 20:46 -0400
Re: Windows binaries 64bit for PHP PlastiqueMAN <plastique@man.com> - 2012-05-23 22:45 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 00:18 -0400
Re: Windows binaries 64bit for PHP Stig Vestøl <stig@vestoldata.no> - 2012-05-24 11:40 +0200
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-24 12:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 09:12 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-24 16:29 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-24 20:41 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 15:17 -0400
Re: Windows binaries 64bit for PHP Luuk <luuk@invalid.lan> - 2012-05-11 21:53 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:15 -0400
Re: Windows binaries 64bit for PHP Luuk <luuk@invalid.lan> - 2012-05-12 10:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 07:29 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-12 06:47 -0500
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:40 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 01:07 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:53 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 08:49 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 08:02 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 21:09 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 15:32 -0400
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-16 17:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-16 12:35 -0400
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-16 19:35 +0200
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-06 18:30 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 19:04 +0200
Re: Windows binaries 64bit for PHP "J.O. Aho" <user@example.net> - 2012-05-12 16:45 +0200
Re: Windows binaries 64bit for PHP "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-05-08 09:49 +0200
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-09 09:17 -0400 |
| Message-ID | <jodqp5$2cp$1@dont-email.me> |
| In reply to | #5867 |
On 5/9/2012 3:56 AM, Erwin Moller wrote: > On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>> .oO(Jerry Stuckle) >>> >>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>> Exactly true, but if you scale to sizes you don't need, you indeed use >>>>> more processor time! Our disk space is definitely not the bottleneck. >>>> >>>> And if you repeatedly rescale the same image to the same size, you're >>>> using even more processor time! >>> >>> You missed the word 'caching'. You rescale when needed, and only once. >> >> How is this different than pre-scaling the images? >> > > Hi Peter, > > It is different because they are *only* rescaled when not found. > > One approach I used: > > 1) Need image xyz_2012_march_nr12_300x500.jpg > (The 300x500 is dimensions needed.) > 2) Check if it exists. > If not: Create it out of original (xyz_2012_march_nr12.jpg in this case) > and store it. > > One can easily wrap this functionality in a function. > > So the difference is that you don't need a batchjob that apparently > needs months and that will resize many images that are never needed, or > never needed on that size. > (I have my doubts about the alleged months, but that doesn't matter.) > > Regards, > Erwin Moller > And another waste of time. You should know what size(s) you need, and be able to prescale your images. I don't think I've ever seen a site which needs more than 3-4 sizes for an image, and most sites don't need that. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-05-09 16:23 +0200 |
| Message-ID | <4faa7dd7$0$6844$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5876 |
On 5/9/2012 3:17 PM, Jerry Stuckle wrote: > On 5/9/2012 3:56 AM, Erwin Moller wrote: >> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>> .oO(Jerry Stuckle) >>>> >>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>> Exactly true, but if you scale to sizes you don't need, you indeed >>>>>> use >>>>>> more processor time! Our disk space is definitely not the bottleneck. >>>>> >>>>> And if you repeatedly rescale the same image to the same size, you're >>>>> using even more processor time! >>>> >>>> You missed the word 'caching'. You rescale when needed, and only once. >>> >>> How is this different than pre-scaling the images? >>> >> >> Hi Peter, >> >> It is different because they are *only* rescaled when not found. >> >> One approach I used: >> >> 1) Need image xyz_2012_march_nr12_300x500.jpg >> (The 300x500 is dimensions needed.) >> 2) Check if it exists. >> If not: Create it out of original (xyz_2012_march_nr12.jpg in this case) >> and store it. >> >> One can easily wrap this functionality in a function. >> >> So the difference is that you don't need a batchjob that apparently >> needs months and that will resize many images that are never needed, or >> never needed on that size. >> (I have my doubts about the alleged months, but that doesn't matter.) >> >> Regards, >> Erwin Moller >> > > And another waste of time. You should know what size(s) you need, and be > able to prescale your images. I don't think I've ever seen a site which > needs more than 3-4 sizes for an image, and most sites don't need that. > It is not that simple, Jerry. When you have simple design-once website: yes, then I agree. But when you deal with a team that uses lots of pictures, you don't want to come back every time some design-guru decides to change the looks of the website and needs different formats for the existing pictures. I rather make a routine and be done with the problem. Regards, Erwin Moller -- "That which can be asserted without evidence, can be dismissed without evidence." -- Christopher Hitchens
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-09 10:38 -0400 |
| Message-ID | <jodvi3$vvq$1@dont-email.me> |
| In reply to | #5878 |
On 5/9/2012 10:23 AM, Erwin Moller wrote: > On 5/9/2012 3:17 PM, Jerry Stuckle wrote: >> On 5/9/2012 3:56 AM, Erwin Moller wrote: >>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>>> .oO(Jerry Stuckle) >>>>> >>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>> Exactly true, but if you scale to sizes you don't need, you indeed >>>>>>> use >>>>>>> more processor time! Our disk space is definitely not the >>>>>>> bottleneck. >>>>>> >>>>>> And if you repeatedly rescale the same image to the same size, you're >>>>>> using even more processor time! >>>>> >>>>> You missed the word 'caching'. You rescale when needed, and only once. >>>> >>>> How is this different than pre-scaling the images? >>>> >>> >>> Hi Peter, >>> >>> It is different because they are *only* rescaled when not found. >>> >>> One approach I used: >>> >>> 1) Need image xyz_2012_march_nr12_300x500.jpg >>> (The 300x500 is dimensions needed.) >>> 2) Check if it exists. >>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this case) >>> and store it. >>> >>> One can easily wrap this functionality in a function. >>> >>> So the difference is that you don't need a batchjob that apparently >>> needs months and that will resize many images that are never needed, or >>> never needed on that size. >>> (I have my doubts about the alleged months, but that doesn't matter.) >>> >>> Regards, >>> Erwin Moller >>> >> >> And another waste of time. You should know what size(s) you need, and be >> able to prescale your images. I don't think I've ever seen a site which >> needs more than 3-4 sizes for an image, and most sites don't need that. >> > > It is not that simple, Jerry. > When you have simple design-once website: yes, then I agree. > > But when you deal with a team that uses lots of pictures, you don't want > to come back every time some design-guru decides to change the looks of > the website and needs different formats for the existing pictures. I > rather make a routine and be done with the problem. > > Regards, > Erwin Moller > > It is even easier than that, Erwin. A quick batch file can easily convert pictures to any size you want. But how often does that happen? My clients don't generally make changes to their site layout very often. And when they do, there's a lot more to it than just converting images. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-05-09 16:54 +0200 |
| Message-ID | <4faa8511$0$6990$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5881 |
On 5/9/2012 4:38 PM, Jerry Stuckle wrote: > On 5/9/2012 10:23 AM, Erwin Moller wrote: >> On 5/9/2012 3:17 PM, Jerry Stuckle wrote: >>> On 5/9/2012 3:56 AM, Erwin Moller wrote: >>>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>>>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>>>> .oO(Jerry Stuckle) >>>>>> >>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>> Exactly true, but if you scale to sizes you don't need, you indeed >>>>>>>> use >>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>> bottleneck. >>>>>>> >>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>> you're >>>>>>> using even more processor time! >>>>>> >>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>> once. >>>>> >>>>> How is this different than pre-scaling the images? >>>>> >>>> >>>> Hi Peter, >>>> >>>> It is different because they are *only* rescaled when not found. >>>> >>>> One approach I used: >>>> >>>> 1) Need image xyz_2012_march_nr12_300x500.jpg >>>> (The 300x500 is dimensions needed.) >>>> 2) Check if it exists. >>>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this >>>> case) >>>> and store it. >>>> >>>> One can easily wrap this functionality in a function. >>>> >>>> So the difference is that you don't need a batchjob that apparently >>>> needs months and that will resize many images that are never needed, or >>>> never needed on that size. >>>> (I have my doubts about the alleged months, but that doesn't matter.) >>>> >>>> Regards, >>>> Erwin Moller >>>> >>> >>> And another waste of time. You should know what size(s) you need, and be >>> able to prescale your images. I don't think I've ever seen a site which >>> needs more than 3-4 sizes for an image, and most sites don't need that. >>> >> >> It is not that simple, Jerry. >> When you have simple design-once website: yes, then I agree. >> >> But when you deal with a team that uses lots of pictures, you don't want >> to come back every time some design-guru decides to change the looks of >> the website and needs different formats for the existing pictures. I >> rather make a routine and be done with the problem. >> >> Regards, >> Erwin Moller >> >> > > It is even easier than that, Erwin. A quick batch file can easily > convert pictures to any size you want. > Yes, I understand that. The point is that I expect less than 1% of them will be used in that format eventually. So it feels like a waste of diskspace to produce them in all formats. > But how often does that happen? My clients don't generally make changes > to their site layout very often. And when they do, there's a lot more to > it than just converting images. > In my case it is a website for city promotion. There is a huge amount of image data, and most is seldom used. Regards, Erwin Moller -- "That which can be asserted without evidence, can be dismissed without evidence." -- Christopher Hitchens
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-09 12:23 -0400 |
| Message-ID | <joe5mi$5t7$2@dont-email.me> |
| In reply to | #5882 |
On 5/9/2012 10:54 AM, Erwin Moller wrote: > On 5/9/2012 4:38 PM, Jerry Stuckle wrote: >> On 5/9/2012 10:23 AM, Erwin Moller wrote: >>> On 5/9/2012 3:17 PM, Jerry Stuckle wrote: >>>> On 5/9/2012 3:56 AM, Erwin Moller wrote: >>>>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>>>>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>>>>> .oO(Jerry Stuckle) >>>>>>> >>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>> Exactly true, but if you scale to sizes you don't need, you indeed >>>>>>>>> use >>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>> bottleneck. >>>>>>>> >>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>> you're >>>>>>>> using even more processor time! >>>>>>> >>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>> once. >>>>>> >>>>>> How is this different than pre-scaling the images? >>>>>> >>>>> >>>>> Hi Peter, >>>>> >>>>> It is different because they are *only* rescaled when not found. >>>>> >>>>> One approach I used: >>>>> >>>>> 1) Need image xyz_2012_march_nr12_300x500.jpg >>>>> (The 300x500 is dimensions needed.) >>>>> 2) Check if it exists. >>>>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this >>>>> case) >>>>> and store it. >>>>> >>>>> One can easily wrap this functionality in a function. >>>>> >>>>> So the difference is that you don't need a batchjob that apparently >>>>> needs months and that will resize many images that are never >>>>> needed, or >>>>> never needed on that size. >>>>> (I have my doubts about the alleged months, but that doesn't matter.) >>>>> >>>>> Regards, >>>>> Erwin Moller >>>>> >>>> >>>> And another waste of time. You should know what size(s) you need, >>>> and be >>>> able to prescale your images. I don't think I've ever seen a site which >>>> needs more than 3-4 sizes for an image, and most sites don't need that. >>>> >>> >>> It is not that simple, Jerry. >>> When you have simple design-once website: yes, then I agree. >>> >>> But when you deal with a team that uses lots of pictures, you don't want >>> to come back every time some design-guru decides to change the looks of >>> the website and needs different formats for the existing pictures. I >>> rather make a routine and be done with the problem. >>> >>> Regards, >>> Erwin Moller >>> >>> >> >> It is even easier than that, Erwin. A quick batch file can easily >> convert pictures to any size you want. >> > > Yes, I understand that. > The point is that I expect less than 1% of them will be used in that > format eventually. So it feels like a waste of diskspace to produce them > in all formats. > > >> But how often does that happen? My clients don't generally make changes >> to their site layout very often. And when they do, there's a lot more to >> it than just converting images. >> > > In my case it is a website for city promotion. > There is a huge amount of image data, and most is seldom used. > > Regards, > Erwin Moller > > So? You know what sizes you need (or at least you should). You don't need every possible size from 1x1 to 1000x1000 pixels. And "seldom used" is not the same as "unused". -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-05-11 13:23 +0200 |
| Message-ID | <4facf691$0$6963$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5888 |
On 5/9/2012 6:23 PM, Jerry Stuckle wrote: > On 5/9/2012 10:54 AM, Erwin Moller wrote: >> On 5/9/2012 4:38 PM, Jerry Stuckle wrote: >>> On 5/9/2012 10:23 AM, Erwin Moller wrote: >>>> On 5/9/2012 3:17 PM, Jerry Stuckle wrote: >>>>> On 5/9/2012 3:56 AM, Erwin Moller wrote: >>>>>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>>>>>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>>>>>> .oO(Jerry Stuckle) >>>>>>>> >>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>>>> indeed >>>>>>>>>> use >>>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>>> bottleneck. >>>>>>>>> >>>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>>> you're >>>>>>>>> using even more processor time! >>>>>>>> >>>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>>> once. >>>>>>> >>>>>>> How is this different than pre-scaling the images? >>>>>>> >>>>>> >>>>>> Hi Peter, >>>>>> >>>>>> It is different because they are *only* rescaled when not found. >>>>>> >>>>>> One approach I used: >>>>>> >>>>>> 1) Need image xyz_2012_march_nr12_300x500.jpg >>>>>> (The 300x500 is dimensions needed.) >>>>>> 2) Check if it exists. >>>>>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this >>>>>> case) >>>>>> and store it. >>>>>> >>>>>> One can easily wrap this functionality in a function. >>>>>> >>>>>> So the difference is that you don't need a batchjob that apparently >>>>>> needs months and that will resize many images that are never >>>>>> needed, or >>>>>> never needed on that size. >>>>>> (I have my doubts about the alleged months, but that doesn't matter.) >>>>>> >>>>>> Regards, >>>>>> Erwin Moller >>>>>> >>>>> >>>>> And another waste of time. You should know what size(s) you need, >>>>> and be >>>>> able to prescale your images. I don't think I've ever seen a site >>>>> which >>>>> needs more than 3-4 sizes for an image, and most sites don't need >>>>> that. >>>>> >>>> >>>> It is not that simple, Jerry. >>>> When you have simple design-once website: yes, then I agree. >>>> >>>> But when you deal with a team that uses lots of pictures, you don't >>>> want >>>> to come back every time some design-guru decides to change the looks of >>>> the website and needs different formats for the existing pictures. I >>>> rather make a routine and be done with the problem. >>>> >>>> Regards, >>>> Erwin Moller >>>> >>>> >>> >>> It is even easier than that, Erwin. A quick batch file can easily >>> convert pictures to any size you want. >>> >> >> Yes, I understand that. >> The point is that I expect less than 1% of them will be used in that >> format eventually. So it feels like a waste of diskspace to produce them >> in all formats. >> >> >>> But how often does that happen? My clients don't generally make changes >>> to their site layout very often. And when they do, there's a lot more to >>> it than just converting images. >>> >> >> In my case it is a website for city promotion. >> There is a huge amount of image data, and most is seldom used. >> >> Regards, >> Erwin Moller >> >> > > So? You know what sizes you need (or at least you should). How should I know? These web designers change their mind every congress they visit. I think it is easier to offer a simple way with dynamic scaling (AND storing) that takes the best of both worlds: little wasted diskspace and fast performance. You don't > need every possible size from 1x1 to 1000x1000 pixels. No, but since I don't know beforehand WHAT they want tomorrow, I think this approach is handy. Regards, Erwin Moller -- "That which can be asserted without evidence, can be dismissed without evidence." -- Christopher Hitchens
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 07:38 -0400 |
| Message-ID | <joitnj$agu$1@dont-email.me> |
| In reply to | #5958 |
On 5/11/2012 7:23 AM, Erwin Moller wrote: > On 5/9/2012 6:23 PM, Jerry Stuckle wrote: >> On 5/9/2012 10:54 AM, Erwin Moller wrote: >>> On 5/9/2012 4:38 PM, Jerry Stuckle wrote: >>>> On 5/9/2012 10:23 AM, Erwin Moller wrote: >>>>> On 5/9/2012 3:17 PM, Jerry Stuckle wrote: >>>>>> On 5/9/2012 3:56 AM, Erwin Moller wrote: >>>>>>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>>>>>>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>>>>>>> .oO(Jerry Stuckle) >>>>>>>>> >>>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>>>>> indeed >>>>>>>>>>> use >>>>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>>>> bottleneck. >>>>>>>>>> >>>>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>>>> you're >>>>>>>>>> using even more processor time! >>>>>>>>> >>>>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>>>> once. >>>>>>>> >>>>>>>> How is this different than pre-scaling the images? >>>>>>>> >>>>>>> >>>>>>> Hi Peter, >>>>>>> >>>>>>> It is different because they are *only* rescaled when not found. >>>>>>> >>>>>>> One approach I used: >>>>>>> >>>>>>> 1) Need image xyz_2012_march_nr12_300x500.jpg >>>>>>> (The 300x500 is dimensions needed.) >>>>>>> 2) Check if it exists. >>>>>>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this >>>>>>> case) >>>>>>> and store it. >>>>>>> >>>>>>> One can easily wrap this functionality in a function. >>>>>>> >>>>>>> So the difference is that you don't need a batchjob that apparently >>>>>>> needs months and that will resize many images that are never >>>>>>> needed, or >>>>>>> never needed on that size. >>>>>>> (I have my doubts about the alleged months, but that doesn't >>>>>>> matter.) >>>>>>> >>>>>>> Regards, >>>>>>> Erwin Moller >>>>>>> >>>>>> >>>>>> And another waste of time. You should know what size(s) you need, >>>>>> and be >>>>>> able to prescale your images. I don't think I've ever seen a site >>>>>> which >>>>>> needs more than 3-4 sizes for an image, and most sites don't need >>>>>> that. >>>>>> >>>>> >>>>> It is not that simple, Jerry. >>>>> When you have simple design-once website: yes, then I agree. >>>>> >>>>> But when you deal with a team that uses lots of pictures, you don't >>>>> want >>>>> to come back every time some design-guru decides to change the >>>>> looks of >>>>> the website and needs different formats for the existing pictures. I >>>>> rather make a routine and be done with the problem. >>>>> >>>>> Regards, >>>>> Erwin Moller >>>>> >>>>> >>>> >>>> It is even easier than that, Erwin. A quick batch file can easily >>>> convert pictures to any size you want. >>>> >>> >>> Yes, I understand that. >>> The point is that I expect less than 1% of them will be used in that >>> format eventually. So it feels like a waste of diskspace to produce them >>> in all formats. >>> >>> >>>> But how often does that happen? My clients don't generally make changes >>>> to their site layout very often. And when they do, there's a lot >>>> more to >>>> it than just converting images. >>>> >>> >>> In my case it is a website for city promotion. >>> There is a huge amount of image data, and most is seldom used. >>> >>> Regards, >>> Erwin Moller >>> >>> >> >> So? You know what sizes you need (or at least you should). > > How should I know? > These web designers change their mind every congress they visit. > No problem - a simple batch job rescales the images to whatever size you specify. > I think it is easier to offer a simple way with dynamic scaling (AND > storing) that takes the best of both worlds: little wasted diskspace and > fast performance. > > You don't >> need every possible size from 1x1 to 1000x1000 pixels. > > No, but since I don't know beforehand WHAT they want tomorrow, I think > this approach is handy. > > Regards, > Erwin Moller > > So? They tell you they need a new size. Run the batch job to create the files. It would take you maybe 10 seconds to type the command in. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-05-11 15:44 +0200 |
| Message-ID | <4fad17cf$0$6959$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5959 |
On 5/11/2012 1:38 PM, Jerry Stuckle wrote: > On 5/11/2012 7:23 AM, Erwin Moller wrote: >> On 5/9/2012 6:23 PM, Jerry Stuckle wrote: >>> On 5/9/2012 10:54 AM, Erwin Moller wrote: >>>> On 5/9/2012 4:38 PM, Jerry Stuckle wrote: >>>>> On 5/9/2012 10:23 AM, Erwin Moller wrote: >>>>>> On 5/9/2012 3:17 PM, Jerry Stuckle wrote: >>>>>>> On 5/9/2012 3:56 AM, Erwin Moller wrote: >>>>>>>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>>>>>>>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>>>>>>>> .oO(Jerry Stuckle) >>>>>>>>>> >>>>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>>>>>> indeed >>>>>>>>>>>> use >>>>>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>>>>> bottleneck. >>>>>>>>>>> >>>>>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>>>>> you're >>>>>>>>>>> using even more processor time! >>>>>>>>>> >>>>>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>>>>> once. >>>>>>>>> >>>>>>>>> How is this different than pre-scaling the images? >>>>>>>>> >>>>>>>> >>>>>>>> Hi Peter, >>>>>>>> >>>>>>>> It is different because they are *only* rescaled when not found. >>>>>>>> >>>>>>>> One approach I used: >>>>>>>> >>>>>>>> 1) Need image xyz_2012_march_nr12_300x500.jpg >>>>>>>> (The 300x500 is dimensions needed.) >>>>>>>> 2) Check if it exists. >>>>>>>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this >>>>>>>> case) >>>>>>>> and store it. >>>>>>>> >>>>>>>> One can easily wrap this functionality in a function. >>>>>>>> >>>>>>>> So the difference is that you don't need a batchjob that apparently >>>>>>>> needs months and that will resize many images that are never >>>>>>>> needed, or >>>>>>>> never needed on that size. >>>>>>>> (I have my doubts about the alleged months, but that doesn't >>>>>>>> matter.) >>>>>>>> >>>>>>>> Regards, >>>>>>>> Erwin Moller >>>>>>>> >>>>>>> >>>>>>> And another waste of time. You should know what size(s) you need, >>>>>>> and be >>>>>>> able to prescale your images. I don't think I've ever seen a site >>>>>>> which >>>>>>> needs more than 3-4 sizes for an image, and most sites don't need >>>>>>> that. >>>>>>> >>>>>> >>>>>> It is not that simple, Jerry. >>>>>> When you have simple design-once website: yes, then I agree. >>>>>> >>>>>> But when you deal with a team that uses lots of pictures, you don't >>>>>> want >>>>>> to come back every time some design-guru decides to change the >>>>>> looks of >>>>>> the website and needs different formats for the existing pictures. I >>>>>> rather make a routine and be done with the problem. >>>>>> >>>>>> Regards, >>>>>> Erwin Moller >>>>>> >>>>>> >>>>> >>>>> It is even easier than that, Erwin. A quick batch file can easily >>>>> convert pictures to any size you want. >>>>> >>>> >>>> Yes, I understand that. >>>> The point is that I expect less than 1% of them will be used in that >>>> format eventually. So it feels like a waste of diskspace to produce >>>> them >>>> in all formats. >>>> >>>> >>>>> But how often does that happen? My clients don't generally make >>>>> changes >>>>> to their site layout very often. And when they do, there's a lot >>>>> more to >>>>> it than just converting images. >>>>> >>>> >>>> In my case it is a website for city promotion. >>>> There is a huge amount of image data, and most is seldom used. >>>> >>>> Regards, >>>> Erwin Moller >>>> >>>> >>> >>> So? You know what sizes you need (or at least you should). >> >> How should I know? >> These web designers change their mind every congress they visit. >> > > No problem - a simple batch job rescales the images to whatever size you > specify. That is one way. It will take up a huge amount of diskspace, defining images that are never used. I don't see the point in approaching it like that. Of course: when you have a small site that seldom changes, there is no need for the approach, but when you deal with many images and designers that want them in other formats on a regular basis, it is smarter to define them on demand. All you need for this is some approach that catches missing images, which van be easily handles by, for example, Apache. To be honest: I don't understand your reluctance at all. Regards, Erwin Moller -- "That which can be asserted without evidence, can be dismissed without evidence." -- Christopher Hitchens
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 10:30 -0400 |
| Message-ID | <joj7qr$4fh$2@dont-email.me> |
| In reply to | #5962 |
On 5/11/2012 9:44 AM, Erwin Moller wrote: > On 5/11/2012 1:38 PM, Jerry Stuckle wrote: >> On 5/11/2012 7:23 AM, Erwin Moller wrote: >>> On 5/9/2012 6:23 PM, Jerry Stuckle wrote: >>>> On 5/9/2012 10:54 AM, Erwin Moller wrote: >>>>> On 5/9/2012 4:38 PM, Jerry Stuckle wrote: >>>>>> On 5/9/2012 10:23 AM, Erwin Moller wrote: >>>>>>> On 5/9/2012 3:17 PM, Jerry Stuckle wrote: >>>>>>>> On 5/9/2012 3:56 AM, Erwin Moller wrote: >>>>>>>>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>>>>>>>>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>>>>>>>>> .oO(Jerry Stuckle) >>>>>>>>>>> >>>>>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>>>>>>> indeed >>>>>>>>>>>>> use >>>>>>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>>>>>> bottleneck. >>>>>>>>>>>> >>>>>>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>>>>>> you're >>>>>>>>>>>> using even more processor time! >>>>>>>>>>> >>>>>>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>>>>>> once. >>>>>>>>>> >>>>>>>>>> How is this different than pre-scaling the images? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Peter, >>>>>>>>> >>>>>>>>> It is different because they are *only* rescaled when not found. >>>>>>>>> >>>>>>>>> One approach I used: >>>>>>>>> >>>>>>>>> 1) Need image xyz_2012_march_nr12_300x500.jpg >>>>>>>>> (The 300x500 is dimensions needed.) >>>>>>>>> 2) Check if it exists. >>>>>>>>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this >>>>>>>>> case) >>>>>>>>> and store it. >>>>>>>>> >>>>>>>>> One can easily wrap this functionality in a function. >>>>>>>>> >>>>>>>>> So the difference is that you don't need a batchjob that >>>>>>>>> apparently >>>>>>>>> needs months and that will resize many images that are never >>>>>>>>> needed, or >>>>>>>>> never needed on that size. >>>>>>>>> (I have my doubts about the alleged months, but that doesn't >>>>>>>>> matter.) >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Erwin Moller >>>>>>>>> >>>>>>>> >>>>>>>> And another waste of time. You should know what size(s) you need, >>>>>>>> and be >>>>>>>> able to prescale your images. I don't think I've ever seen a site >>>>>>>> which >>>>>>>> needs more than 3-4 sizes for an image, and most sites don't need >>>>>>>> that. >>>>>>>> >>>>>>> >>>>>>> It is not that simple, Jerry. >>>>>>> When you have simple design-once website: yes, then I agree. >>>>>>> >>>>>>> But when you deal with a team that uses lots of pictures, you don't >>>>>>> want >>>>>>> to come back every time some design-guru decides to change the >>>>>>> looks of >>>>>>> the website and needs different formats for the existing pictures. I >>>>>>> rather make a routine and be done with the problem. >>>>>>> >>>>>>> Regards, >>>>>>> Erwin Moller >>>>>>> >>>>>>> >>>>>> >>>>>> It is even easier than that, Erwin. A quick batch file can easily >>>>>> convert pictures to any size you want. >>>>>> >>>>> >>>>> Yes, I understand that. >>>>> The point is that I expect less than 1% of them will be used in that >>>>> format eventually. So it feels like a waste of diskspace to produce >>>>> them >>>>> in all formats. >>>>> >>>>> >>>>>> But how often does that happen? My clients don't generally make >>>>>> changes >>>>>> to their site layout very often. And when they do, there's a lot >>>>>> more to >>>>>> it than just converting images. >>>>>> >>>>> >>>>> In my case it is a website for city promotion. >>>>> There is a huge amount of image data, and most is seldom used. >>>>> >>>>> Regards, >>>>> Erwin Moller >>>>> >>>>> >>>> >>>> So? You know what sizes you need (or at least you should). >>> >>> How should I know? >>> These web designers change their mind every congress they visit. >>> >> >> No problem - a simple batch job rescales the images to whatever size you >> specify. > > That is one way. > It will take up a huge amount of diskspace, defining images that are > never used. > I don't see the point in approaching it like that. > > Of course: when you have a small site that seldom changes, there is no > need for the approach, but when you deal with many images and designers > that want them in other formats on a regular basis, it is smarter to > define them on demand. > All you need for this is some approach that catches missing images, > which van be easily handles by, for example, Apache. > > To be honest: I don't understand your reluctance at all. > > Regards, > Erwin Moller > > In case you haven't figured it out - disk space is cheap - much cheaper than CPU. But then if you're only getting 200 hits a day I guess the extra load doesn't make any difference. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2012-05-11 13:38 -0500 |
| Message-ID | <slrnjqqn4l.4ci.hellsop@nibelheim.ninehells.com> |
| In reply to | #5962 |
On Fri, 11 May 2012 15:44:55 +0200, Erwin Moller wrote:
> On 5/11/2012 1:38 PM, Jerry Stuckle wrote:
>>
>> No problem - a simple batch job rescales the images to whatever size you
>> specify.
>
> That is one way.
> It will take up a huge amount of diskspace, defining images that are
> never used.
> I don't see the point in approaching it like that.
Why are the designers asking you for image sizes that will never be
used? (Aside from the admittedly-true "They're WEB DESIGNERS"...)
--
Windows gives you a nice view of clouds so you can't see any potentially
useful boot time messages.
-- Bill Hay in the Monastery
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-05-14 10:48 +0200 |
| Message-ID | <4fb0c6d2$0$6963$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5971 |
On 5/11/2012 8:38 PM, Peter H. Coffin wrote: > On Fri, 11 May 2012 15:44:55 +0200, Erwin Moller wrote: >> On 5/11/2012 1:38 PM, Jerry Stuckle wrote: >>> >>> No problem - a simple batch job rescales the images to whatever size you >>> specify. >> >> That is one way. >> It will take up a huge amount of diskspace, defining images that are >> never used. >> I don't see the point in approaching it like that. > > Why are the designers asking you for image sizes that will never be > used? (Aside from the admittedly-true "They're WEB DESIGNERS"...) > Hi Peter, The content makers use these pictures and the designers create the presentation layers. It worked like this: - We have a stock of high res pictures on some dedicated server. - A bunch of domains (all related) use these pictures, in different dimensions. - A lot of third parties request the info and will use it in ever changing context (RSS feeds, websites, mobile apps, flyers, desktop publishing, etc). Now there are (at least) two approaches: 1) pull the pictures from the pictureserver, and resize them in the domain where they are used. 2) Let the picture server decide (based on filename) what dimensions the requested picture should be. We did this. The pictureserver had some services like delivering small pictures on some subject, so the content maker can pick the right one. The pictureserver also can count how often which picture is requested: in some cases there were fees involved to the owner of the picture. (Of course this can all be circumvented.) There are different approaches to solve the same problem: I know that. I merely posted in this thread to say that dynamic resizing combined with storing that file can have it uses in certain situations. I also think it isn't always the smartest solution to resize them all beforehand, like Jerry prefers. Regards, Erwin Moller -- "That which can be asserted without evidence, can be dismissed without evidence." -- Christopher Hitchens
[toc] | [prev] | [next] | [standalone]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2012-05-09 11:34 -0500 |
| Message-ID | <slrnjql74a.4ci.hellsop@nibelheim.ninehells.com> |
| In reply to | #5867 |
On Wed, 09 May 2012 09:56:44 +0200, Erwin Moller wrote: > On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>> .oO(Jerry Stuckle) >>> >>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>> Exactly true, but if you scale to sizes you don't need, you indeed use >>>>> more processor time! Our disk space is definitely not the bottleneck. >>>> >>>> And if you repeatedly rescale the same image to the same size, you're >>>> using even more processor time! >>> >>> You missed the word 'caching'. You rescale when needed, and only once. >> >> How is this different than pre-scaling the images? >> > > Hi Peter, > > It is different because they are *only* rescaled when not found. > > One approach I used: > > 1) Need image xyz_2012_march_nr12_300x500.jpg > (The 300x500 is dimensions needed.) > 2) Check if it exists. > If not: Create it out of original (xyz_2012_march_nr12.jpg in this case) > and store it. > > One can easily wrap this functionality in a function. > > So the difference is that you don't need a batchjob that apparently > needs months and that will resize many images that are never needed, or > never needed on that size. > (I have my doubts about the alleged months, but that doesn't matter.) Still seems a waste to use webserver CPU to do something that's apparently time-critical and intensive to do what could be handled as part of a production build. I mean, don't you KNOW what size image you're going to need? Will you suddenly need xyz_2012_march_nr12_318x1260.jpg ? Or are you working around someone just forgetting to build something that IS known about and should be part of a documented process? -- _ o |/)
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-05-09 11:30 -0700 |
| Message-ID | <cJyqr.1384$3y3.872@newsfe20.iad> |
| In reply to | #5891 |
On 5/9/12 9:34 AM, Peter H. Coffin wrote: > On Wed, 09 May 2012 09:56:44 +0200, Erwin Moller wrote: >> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>> .oO(Jerry Stuckle) >>>> >>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>> Exactly true, but if you scale to sizes you don't need, you indeed use >>>>>> more processor time! Our disk space is definitely not the bottleneck. >>>>> >>>>> And if you repeatedly rescale the same image to the same size, you're >>>>> using even more processor time! >>>> >>>> You missed the word 'caching'. You rescale when needed, and only once. >>> >>> How is this different than pre-scaling the images? >>> >> >> Hi Peter, >> >> It is different because they are *only* rescaled when not found. >> >> One approach I used: >> >> 1) Need image xyz_2012_march_nr12_300x500.jpg >> (The 300x500 is dimensions needed.) >> 2) Check if it exists. >> If not: Create it out of original (xyz_2012_march_nr12.jpg in this case) >> and store it. >> >> One can easily wrap this functionality in a function. >> >> So the difference is that you don't need a batchjob that apparently >> needs months and that will resize many images that are never needed, or >> never needed on that size. >> (I have my doubts about the alleged months, but that doesn't matter.) > > Still seems a waste to use webserver CPU to do something that's > apparently time-critical and intensive to do what could be handled as > part of a production build. I mean, don't you KNOW what size image > you're going to need? Will you suddenly need > xyz_2012_march_nr12_318x1260.jpg ? Or are you working around someone > just forgetting to build something that IS known about and should be > part of a documented process? > Our content producers upload images using our CMS and, they currently get scaled to the "common" sizes. We currently have a catalog of 7.5 million images. Now, it happens every so often that one of our (many) design teams or product teams decide that one of our (many) sites needs a redesign. When that happens, sometimes they want a new size (or have some specific cropping requirements, etc...). If it takes 1 second to reprocess an image (and it averages much higher than that), it would take 12 days to reprocess our entire catalog. We are not a little shop working on a site for a single client. We are a large media company. Some things that work with small to medium sized sites do not work at all when you're dealing with millions of images. The point is, if you don't need dynamic resizing, good for you, don't go to the trouble. Some of us on the other hand work on a different scale.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-09 15:52 -0400 |
| Message-ID | <joehue$ofs$1@dont-email.me> |
| In reply to | #5892 |
On 5/9/2012 2:30 PM, Daniel Pitts wrote: > On 5/9/12 9:34 AM, Peter H. Coffin wrote: >> On Wed, 09 May 2012 09:56:44 +0200, Erwin Moller wrote: >>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>>> .oO(Jerry Stuckle) >>>>> >>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>> indeed use >>>>>>> more processor time! Our disk space is definitely not the >>>>>>> bottleneck. >>>>>> >>>>>> And if you repeatedly rescale the same image to the same size, you're >>>>>> using even more processor time! >>>>> >>>>> You missed the word 'caching'. You rescale when needed, and only once. >>>> >>>> How is this different than pre-scaling the images? >>>> >>> >>> Hi Peter, >>> >>> It is different because they are *only* rescaled when not found. >>> >>> One approach I used: >>> >>> 1) Need image xyz_2012_march_nr12_300x500.jpg >>> (The 300x500 is dimensions needed.) >>> 2) Check if it exists. >>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this case) >>> and store it. >>> >>> One can easily wrap this functionality in a function. >>> >>> So the difference is that you don't need a batchjob that apparently >>> needs months and that will resize many images that are never needed, or >>> never needed on that size. >>> (I have my doubts about the alleged months, but that doesn't matter.) >> >> Still seems a waste to use webserver CPU to do something that's >> apparently time-critical and intensive to do what could be handled as >> part of a production build. I mean, don't you KNOW what size image >> you're going to need? Will you suddenly need >> xyz_2012_march_nr12_318x1260.jpg ? Or are you working around someone >> just forgetting to build something that IS known about and should be >> part of a documented process? >> > > > Our content producers upload images using our CMS and, they currently > get scaled to the "common" sizes. We currently have a catalog of 7.5 > million images. > > Now, it happens every so often that one of our (many) design teams or > product teams decide that one of our (many) sites needs a redesign. When > that happens, sometimes they want a new size (or have some specific > cropping requirements, etc...). > > If it takes 1 second to reprocess an image (and it averages much higher > than that), it would take 12 days to reprocess our entire catalog. > > We are not a little shop working on a site for a single client. We are a > large media company. Some things that work with small to medium sized > sites do not work at all when you're dealing with millions of images. > > The point is, if you don't need dynamic resizing, good for you, don't go > to the trouble. Some of us on the other hand work on a different scale. You need to get rid of that TRS-80 and get a decent machine. It shouldn't take anywhere near a second to resize an image. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-05-09 13:46 -0700 |
| Message-ID | <nIAqr.3942$br3.624@newsfe10.iad> |
| In reply to | #5897 |
On 5/9/12 12:52 PM, Jerry Stuckle wrote: > On 5/9/2012 2:30 PM, Daniel Pitts wrote: >> On 5/9/12 9:34 AM, Peter H. Coffin wrote: >>> On Wed, 09 May 2012 09:56:44 +0200, Erwin Moller wrote: >>>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote: >>>>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >>>>>> .oO(Jerry Stuckle) >>>>>> >>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>> indeed use >>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>> bottleneck. >>>>>>> >>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>> you're >>>>>>> using even more processor time! >>>>>> >>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>> once. >>>>> >>>>> How is this different than pre-scaling the images? >>>>> >>>> >>>> Hi Peter, >>>> >>>> It is different because they are *only* rescaled when not found. >>>> >>>> One approach I used: >>>> >>>> 1) Need image xyz_2012_march_nr12_300x500.jpg >>>> (The 300x500 is dimensions needed.) >>>> 2) Check if it exists. >>>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this >>>> case) >>>> and store it. >>>> >>>> One can easily wrap this functionality in a function. >>>> >>>> So the difference is that you don't need a batchjob that apparently >>>> needs months and that will resize many images that are never needed, or >>>> never needed on that size. >>>> (I have my doubts about the alleged months, but that doesn't matter.) >>> >>> Still seems a waste to use webserver CPU to do something that's >>> apparently time-critical and intensive to do what could be handled as >>> part of a production build. I mean, don't you KNOW what size image >>> you're going to need? Will you suddenly need >>> xyz_2012_march_nr12_318x1260.jpg ? Or are you working around someone >>> just forgetting to build something that IS known about and should be >>> part of a documented process? >>> >> >> >> Our content producers upload images using our CMS and, they currently >> get scaled to the "common" sizes. We currently have a catalog of 7.5 >> million images. >> >> Now, it happens every so often that one of our (many) design teams or >> product teams decide that one of our (many) sites needs a redesign. When >> that happens, sometimes they want a new size (or have some specific >> cropping requirements, etc...). >> >> If it takes 1 second to reprocess an image (and it averages much higher >> than that), it would take 12 days to reprocess our entire catalog. >> >> We are not a little shop working on a site for a single client. We are a >> large media company. Some things that work with small to medium sized >> sites do not work at all when you're dealing with millions of images. >> >> The point is, if you don't need dynamic resizing, good for you, don't go >> to the trouble. Some of us on the other hand work on a different scale. > > You need to get rid of that TRS-80 and get a decent machine. It > shouldn't take anywhere near a second to resize an image. Our source images are often extremely high resolution, so part of the processing time is IO bound. I haven't actually worked on the image processing codebase, and I do suspect there are some efficiencies that could be gained somewhere, but the fact remains that at our scale, dynamic resizing is a better solution.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-09 09:10 -0400 |
| Message-ID | <jodqcr$u0s$1@dont-email.me> |
| In reply to | #5861 |
On 5/8/2012 4:25 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>> Exactly true, but if you scale to sizes you don't need, you indeed use >>> more processor time! Our disk space is definitely not the bottleneck. >> >> And if you repeatedly rescale the same image to the same size, you're >> using even more processor time! > > You missed the word 'caching'. You rescale when needed, and only once. > > Micha > No, I didn't. By definition, caching is temporary storage which can be erased at any time. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-10 00:19 +0200 |
| Message-ID | <sarlq7lavic2n0im3n074fklgfiphofape@mfesser.de> |
| In reply to | #5874 |
.oO(Jerry Stuckle) >On 5/8/2012 4:25 PM, Michael Fesser wrote: >> .oO(Jerry Stuckle) >> >>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>> Exactly true, but if you scale to sizes you don't need, you indeed use >>>> more processor time! Our disk space is definitely not the bottleneck. >>> >>> And if you repeatedly rescale the same image to the same size, you're >>> using even more processor time! >> >> You missed the word 'caching'. You rescale when needed, and only once. > >No, I didn't. By definition, caching is temporary storage which can be >erased at any time. Correct. And then the rescaled images are created again when needed, so what's the problem? It all happens automatically. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-05-09 15:28 -0700 |
| Message-ID | <RbCqr.748$9Q6.157@newsfe18.iad> |
| In reply to | #5899 |
On 5/9/12 3:19 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>> .oO(Jerry Stuckle) >>> >>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>> Exactly true, but if you scale to sizes you don't need, you indeed use >>>>> more processor time! Our disk space is definitely not the bottleneck. >>>> >>>> And if you repeatedly rescale the same image to the same size, you're >>>> using even more processor time! >>> >>> You missed the word 'caching'. You rescale when needed, and only once. >> >> No, I didn't. By definition, caching is temporary storage which can be >> erased at any time. > > Correct. And then the rescaled images are created again when needed, so > what's the problem? It all happens automatically. > > Micha > Caching needn't be temporary, and you can ensure it isn't "erased at any time" by just not erasing the "cache". There are many different types of "cache".
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-09 23:53 -0400 |
| Message-ID | <jofe40$iin$3@dont-email.me> |
| In reply to | #5901 |
On 5/9/2012 6:28 PM, Daniel Pitts wrote: > On 5/9/12 3:19 PM, Michael Fesser wrote: >> .oO(Jerry Stuckle) >> >>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>> .oO(Jerry Stuckle) >>>> >>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>> Exactly true, but if you scale to sizes you don't need, you indeed >>>>>> use >>>>>> more processor time! Our disk space is definitely not the bottleneck. >>>>> >>>>> And if you repeatedly rescale the same image to the same size, you're >>>>> using even more processor time! >>>> >>>> You missed the word 'caching'. You rescale when needed, and only once. >>> >>> No, I didn't. By definition, caching is temporary storage which can be >>> erased at any time. >> >> Correct. And then the rescaled images are created again when needed, so >> what's the problem? It all happens automatically. >> >> Micha >> > > Caching needn't be temporary, and you can ensure it isn't "erased at any > time" by just not erasing the "cache". There are many different types of > "cache". By definition a cache is temporary. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-05-10 13:15 -0700 |
| Message-ID | <ilVqr.4488$iQ.1640@newsfe23.iad> |
| In reply to | #5907 |
On 5/9/12 8:53 PM, Jerry Stuckle wrote: > On 5/9/2012 6:28 PM, Daniel Pitts wrote: >> On 5/9/12 3:19 PM, Michael Fesser wrote: >>> .oO(Jerry Stuckle) >>> >>>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>>> .oO(Jerry Stuckle) >>>>> >>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>> Exactly true, but if you scale to sizes you don't need, you indeed >>>>>>> use >>>>>>> more processor time! Our disk space is definitely not the >>>>>>> bottleneck. >>>>>> >>>>>> And if you repeatedly rescale the same image to the same size, you're >>>>>> using even more processor time! >>>>> >>>>> You missed the word 'caching'. You rescale when needed, and only once. >>>> >>>> No, I didn't. By definition, caching is temporary storage which can be >>>> erased at any time. >>> >>> Correct. And then the rescaled images are created again when needed, so >>> what's the problem? It all happens automatically. >>> >>> Micha >>> >> >> Caching needn't be temporary, and you can ensure it isn't "erased at any >> time" by just not erasing the "cache". There are many different types of >> "cache". > > By definition a cache is temporary. > Whose definition? According to <http://www.thefreedictionary.com/cache> 1. "A collection of items of the same type stored in a hidden or inaccessible place." 2. Computer Science: A fast storage buffer in the central processing unit of a computer. Also called cache memory. That doesn't define it as temporary. Perhaps you're mistaking your understanding of the concept with reality. Reality wins over your understanding. Anyway, I've had enough fun arguing with an obvious "expert" in this field. Enjoy being "right" on the internet. Good day, Daniel.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web