Jesse Thanks for taking the time to explain this.
Macromedia has some interesting choices/alternatives -- shipping Apache source, could easily complicate the release cycle and may not resolve the issue. Are there other manufacturers in a similar situation who can be used as a Model? Apple interfaces their proprietary WebObjects with Apache. I suspect that Apple, IBM and other manufacturers of Application servers / Web Application servers have similar issues. It will be interesting to see how this turns out. Dick Does Macromrdia currently ship Apache On Tuesday, August 13, 2002, at 09:05 AM, Jesse Noller wrote: >> 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] > ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
