> So, for reasons of stability, and simple logistics of product > packaging/testing/release, CFMX will likely be somewhat behind the the > current version of component 3rd-party products -- not the newest > release, but (shall we say) the maturest release.
Correct. This includes Merant Drivers, Verity, Axis, and the kitchen sink. We need to go with what we trust. > > Still, if as reported with Apache, there are security issues being > fixed, this forces Macromedia to start an (unforeseen?) maintenance > release. No - In the case of Apache, this is becoming a bigger and bigger issue whereas we need to reevaluate the manner with which we deploy Apache updates/update the module/ship the module. Apache is a unique entity, and Apache 2.0 takes that a step further. > I am not likely to deploy any production servers, but I would like to > use Apache on the Developer system. The thing that prevents me from > doing so (proprietary C++ code) is the same thing that exacerbates the > the Apache update problem. No - What prevents this is the fact that Macromedia cannot move fast enough to support the newest .revs of Apache. I would beg the argument that while shipping the module code would be nice, it still won't assist in 100% of the cases where you want to run the C module on an unsupported platform/etc. > It would seem that re-architecting the CFMX/JRun/Apache interface to > obviate the proprietary code would: > > Reduce Macromedia's need to initiate unforeseen releases > > Better satisfy the needs of Macromedia's customers (be able to > apply security updates as they become available. > > This would also resolve my developer issue (hey, why not?) > The problem/benefits here have already been hashed over. While removing the intellectual property inside the Connector would allow us to ship the source to the actual apache module, it doesn't change the fact that there would still be a stub that would need to be utilized to communicate between the JRun proxy and the web server. Therefore, this may not "fix" unsupported platforms. However, remember that the code included in the Apache module has features which we utilize, so we are not talking a simple job of stripping out the proprietary code, rather, it would end up becoming a "re-architecture'ing" of the way JRun/CFMX and the web server talk to each other. This means this problem just got bigger. This no longer becomes a "Patch" but rather a .rev of the product (Say CFMX.2). These things are being considered, and management/etc have been notified. -Jesse Noller [EMAIL PROTECTED] ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
