Might need some though on how that comes together -- we're happy to help. Ideally we'd have the hooks in the core and the image-engine anywhere the sys admins want.
I'm currently working on extension and overwriting of core Farcry Components (packages.farcry & packages.security). Once that's done you could plug-in whatever image manipulation software you like. Although there's still the question...What imaging package will Farcry support out of the box? Or should image.cfc simply become an abstract class, "The hook in the core", and the client can drop whatever imaging component they want into their app?
I think we need an out of the box option. The choice of which image library comes down to licensing and functionality. Ideally it could be something we could distribute freely with FarCry without compromising our own CPL licensing.
We have a commercial vertical for brand asset management (FarCry BAM), and we're looking at hooking it potentially up to a dynamic image server or two.. would be nice if we didn't have to bastardise core to do this.
Extension of core components will fit the bill -- if we provide another of these "check project for code and fail to core" routines for images.
I guess it still leaves us with a choice of Image library.. so far we've got:
- ImageJ (limited support already available)
- JAI (nice DRK implementation of this)
- ImageMagick (cf5 customtag library -- appears comprehensive)
It's got to be something that we can easily deploy across a variety of OS. Ideally for out of the box, it shouldn't require anything to be deployed outside of core... like compiling binaries, or sticking class files in the class path etc. Tricky eh ;)
-- geoff http://www.daemon.com.au/
--- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
