|
Wednesday 22 October 2003 4:27:19 am
>- I cannot complain about the performance. For us, the image
> conversion itself (ImageMagick) takes some seconds, which
> is way too much, when the variation needs to be created the
> first time. After that, everything is fine (no production site
> stats yet) The performance we talked about were when the variations are created and the data must be fetched from the database. In itself it's not a huge problem but when you want to do a multi fetch for all attributes of all realated objects you get lots of extra queries and object creations. Regarding the long time it takes to create variations, how about a switch to define which variations should be created when publishing?
> - Backward compatibilty is fine, but don't provide it too long
> (see MS-DOS). It would just crowd the code and not perform
> too well. Provide _good_ upgrade scripts!
Backwards compatability will be maintained in the templates only, that means that you can do content.small.full_path and still get the path to the image. All settings and existing code will be changed.
Also the system will work with the old image tables, it will read in the original information and create a new entry from it. All variations will be removed. The old image filename will also be moved to use the new naming scheme.
And yes, upgrade scripts will be available.
> - I'm not sure, how you will handle more image conversion
> systems. How many are there anyway? You should
> concentrate on fixing the bugs in the current use of
> ImageMagick and GD for now The reason for the current bugs was the design of the image system, now we've done it from scratch with a more sound design. An extra benefit is that it's easier to add new image conversion/filter programs.
> What about the reference image concept? I discussed with
> Bard about this and I would love to remove the need for
> reference images completly. I know, this is handy, when you
> have large images, but we (and quite some other users) will
> not have large images.
There's no longer any explicit reference image, instead you define one or more Image Aliases, each alias has a name a reference to another Image Alias (optional) and a list of filters (Image size is a filter).
If you wanted you could just have the original Image Alias (which is always present, no need to define it).
> - Take care about the ">" character in ImageMagick scaling
> operatoin (ScaleLargeThanOriginal). Avoid that by letting ez
> decide, if scaling should be done or not.
We will see if there is a way around this, the problem was when the > was escaped and the path to the conversion program was also quoted (because of spaces), then the php system() command did not execute the program correctly (at least on windows).
> About the better filenames: I like the idea.
> About your 2 issues:
> 1. Why don't you just go though all versions of the object,
> when it is deleted? Can't be sooo many. Storing the image
> filenames of an object in a seperate table mean duplicate
> storage (another possible point of failure). Perhaps, we're not 100% sure what we will do here.
> 2. I don't like the idea of copying images (or files) in the
> filesystem, just because the object is moved. What about
> doing symlinks? Good idea, at least on linux/unix we can do this.
--
Amos
Documentation: http://ez.no/ez_publish/documentation
FAQ: http://ez.no/ez_publish/documentation/faq
|
