Re: Re: ext/imagick BC break (was: Re: [PEAR-DEV] PHP Magick version 0.5a Released!)

On Tue, 2002-11-26 at 16:38, George Schlossnagle wrote: > Since you're breaking BC, have you considered making the new imagick > interface OO? There is enormous bloat in the php global function table, > keepinf all your method names in a private namespace would be nice. I have considered it back then when I wrote my implementation, but my Zend-Skills were pretty low back then and there are not many extensions which use that approach (domxml in a somehow quite strange way and ming), so I couldn't "steal" from others. The problem nowadays is, that I don't have time to rewrite it in OO fashion, therefore I think, we just have to leave it as it is... chregu > George > > Michael Montero wrote: > > >Quick review, I will work on the doc. and forward around. Will shoot for > >today (althought most of the doc. is already below). These functions are > >supported: > > > >PHP_FUNCTION(imagick_border); > >PHP_FUNCTION(imagick_frame); > >PHP_FUNCTION(imagick_resize); > >PHP_FUNCTION(imagick_sample); > >PHP_FUNCTION(imagick_crop); > >PHP_FUNCTION(imagick_rotate); > >PHP_FUNCTION(imagick_shear); > >PHP_FUNCTION(imagick_oilpaint); > >PHP_FUNCTION(imagick_annotate); > >PHP_FUNCTION(imagick_convert); > > > >I haven't looked at each specifically but there is a chance the parameter > >order changed. UNLESS (and I believe Christian and I followed this > >standard) the handle is the first parameter and the subsequent parameters > >match the order in which they are passed to the ImageMagick functions. I > >looked at imagick_resize (old one) and the new one and they are dead on. > > > >These functions have been made backward compatible: > > > > PHP_FUNCTION( imagick_read ) ; /* => imagick_readimage() */ > > PHP_FUNCTION( imagick_write ) ; /* => imagick_writeimage() */ > > PHP_FUNCTION( imagick_free ) ; /* => imagick_destroyhandle() */ > > > >These have been deprecated: > > > > PHP_FUNCTION( imagick_add_resource ) ; > > PHP_FUNCTION( imagick_list_magickinfo ) ; > > PHP_FUNCTION( imagick_new ) ; > > PHP_FUNCTION( imagick_init ) ; > > PHP_FUNCTION( imagick_copy_sample ) ; > > PHP_FUNCTION( imagick_copy_resize ) ; > > PHP_FUNCTION( imagick_copy_crop ) ; > > PHP_FUNCTION( imagick_copy_shear ) ; > > PHP_FUNCTION( imagick_copy_rotate ) ; > > PHP_FUNCTION( imagick_copy_morph ) ; > > PHP_FUNCTION( imagick_dump ) ; > > > >A few explanations: > > > >imagick_add_resource() and imagick_list_magickinfo() aren't entirely > >necessary anymore. The phpinfo() will list everything that > >imagick_list_magickinfo() would dump to a file. If anyone disagrees, I > >can implement the function but I'd rather the data in phpinfo() then > >requesting PHP to dump a file. imagick_add_resource() will be supported > >in SOME fashion with regard to image lists. I believe this will use the > >ImageMagick push functions and should appear perhaps today. If I CAN make > >this function backwards compatible I will. > > > >imagick_new() has no meaning...to create a new handle you either have to > >create a canvas or read an image. Currently you can read an image from a > >file and by the time we're done from a blob of data as well. You can > >create a canvas of a specified size and color. Coming soon will be > >creating a canvas with a tiled background created from a custom image. > > > >imagick_init() isn't necessary anymore. ImageMagick needs to be > >initialized but I have removed the need for the user to remember doing > >this. The module will initialize itself and clean up after itself. > > > >imagick_copy* functions are too ambitious. The ImageMagick library is > >enormous and writing a corresponding copy function for every operation, in > >my opinion, is a wasted efforted (again, based solely on the number of > >functions available in ImageMagick). Instead, I support this: > > > ><? > > $existing_handle = imagick_readimage( "./image.jpg" ) ; > > $new_handle = imagick_clonehandle( $existing_handle ) ; > > > > // now execute a function on the cloned handled > >?> > > > >In other words, instead of the function creating a new handle and > >returning it to you, you'd create a new handle and operate on it. > > > >imagick_dump(): I thought about this a lot. This essentially writes the > >image file out, then reads it and writes it to the browser. This seems > >like a lot of effort if all the user wants to do is work on an image and then > >just display it. You can achieve this with the new API by doing: > > > ><? > > $handle = imagick_readimage( "./image.jpg" ) ; > > > > header( "Content-type: " . imagick_getmimetype( $handle ) ) ; > > print $image_data = imagick_image2blob( $handle ) ; > >?> > > > >If you want to write the file you can do so at another point or not do it > >at all. > > > >If anyone disagrees with this assessment let me know. I can put some work > >into some of it. However, I'm pretty opposed to the copy functions. > >There would need to be something like 20 or 30 (perhaps more) in addition > >to the same functions that operate on image itself without copying it. This > >seems like far too much to support. It makes more sense to me to let the > >user clone the handle when that's what they want and start operating on a > >different image entirely. > > > >Let me know what you think. > > > >On Tue, 26 Nov 2002, Alan Knowles wrote: > > > >>Michael Montero wrote: > >> > >>>I will clearly document how to go from the BC version to the new one. > >>> > >>can you give a 2-3 line overview of the differences: > >>functions have different arguments/order? > >>missing functions? > >>(lots of new ones I presume :) ... > >> > >>phpmole uses it to do resize/rotate etc. > >>Regards > >>Alan > >> > >> > >>> > >>> > >>>On Mon, 25 Nov 2002, Christian Stocker wrote: > >>> > >>> > >>> > >>>>Hi > >>>> > >>>>As mentioned in the mail by Michael, we will replace pecl/imagick with his > >>>>version, as I think, he has much more to offer than my code (and much more > >>>>time to support it right at the moment :) ). I will still support the > >>>>extension and hopefully contribute to it. > >>>> > >>>>Therefore here comes the big WARNING: > >>>> > >>>>The commits (and finally releases) in the next few days will break BC of > >>>>pecl/imagick! Therefore, if anyone is using this extension and really > >>>>really needs BC should stand up now and maybe we will have a look what we > >>>>can do :) But since it's clearly stated as alpha and experimental, noone > >>>>should be surprised by that > >>>> > >>>>Anyway, have a nice evening and check out Michael's work. > >>>> > >>>>christian > >>>> > >>>> > >>>> > >>>>On Mon, 25 Nov 2002, Michael Montero wrote: > >>>> > >>>> > >>>> > >>>>>Just released some more functionality. The major push right now is join > >>>>>my efforts with those of Christian Stocker to get one single module into > >>>>>PEAR. Christian and I have been working that. Please see the latest > >>>>>changes below...they are significant. > >>>>> > >>>>> - functions added: > >>>>> imagick_getcanvas() > >>>>> imagick_blur() > >>>>> imagick_despeckle() > >>>>> imagick_edge() > >>>>> imagick_emboss() > >>>>> imagick_enhance() > >>>>> imagick_gaussianblur() > >>>>> imagick_medianfilter() > >>>>> imagick_motionblur() > >>>>> - one major change - renamed everything to imagick*; I've > >>>>> joined > >>>>> my efforts with Christian Stocker who had a previously written > >>>>> but smaller extension > >>>>> - magick_getcanvas() allows you to create a blank image to draw on > >>>>> - changed comment header in imagick.h to match the one in > >>>>> imagick.c > >>>>> - added Christian Stocker to credits > >>>>> - moved over to Christian Stocker's config.m4, removed the need > >>>>> for gen_configm4 > >>>>> - rewrote INSTALL to reflect new config.m4 > >>>>> - slight modifications to config.m4 to get it to work properly > >>>>> - added package.xml > >>>>> - removed ChangeLog, everything is now in package.xml > >>>>> - removed imagick_free_reason() and imagick_free_description() > >>>>> since they are no longer necessary > >>>>> - preceded all internal functions with _php_ > >>>>> - created imagick_read() for backward compatibility with old > >>>>> extension > >>>>> - created imagick_write() for backward compatibility with old > >>>>> extension > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > -- christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB