Jesse
Good answers -- I understand.
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.
Still, if as reported with Apache, there are security issues being
fixed, this forces Macromedia to start an (unforeseen?) maintenance
release.
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.
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?)
Dick
On Tuesday, August 13, 2002, at 05:28 AM, Jesse Noller wrote:
> Dick-
>
> Simple put, this is not "painting ourselves" into a corner. For
> the most part, there are reasons WHY we don't want you to upgrade to
> the latest bleeding edge version of X (minus apache).
>
> To put it simply: "upgrading" to the latest version of Axis would
> require a full gambit of internal regression tests, etc. This means
> that every time axis released a .rev we'd have to run full-blown
> compatibility tests.
>
> It's as if I want to support every .rev of glibc, etc for an
> end-user system. That's why we package that version of the software,
> and that's why our supported platforms/java versions are quite specific.
>
> If you want to take advantage of the latest bleeding edge
> development tree, I'd say go for it, however, we are not in the
> "bleeding edge .rev" market. We're supposed to give you, the consumer,
> a stable, affordable product where we can say "we can reasonably
> support this".
>
> If we spend all of our time testing dev trees for 3rd party
> components then we don't get to do that. There'd be a new CFMX patch
> out every day if CVS doesn't lie.
>
> As for Apache: Apache 2.0 is a unique beast. They keep changing
> magic numbers/etc, which breaks module compatibility. The issues with
> the Apache module are already known. The issues are being worked on.
>
>
>
> Jesse Noller
> [EMAIL PROTECTED]
> Macromedia Server Development
> Unix/Linux "special guy"
>
>> -----Original Message-----
>> From: Dick Applebaum [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, August 12, 2002 6:11 PM
>> To: CF-Talk
>> Subject: [SOT] Is MM painting itself into a corner?
>>
>> There have been several threads about upgrading CFMX to work with the
>> latest:
>>
>> Apache server
>>
>> Axis
>>
>> Java
>>
>> and there are probably some other 3-rd party products that CFMX
>> interfaces/depends upon
>>
>> From what I gather from reading these threads, the "common problem"
>> with
>> upgrading to the latest version of these products is that the interface
>> to them is proprietary Macromedia code?
>>
>> If this is true, will we be forever behind on upgrades of these 3-rd
>> party products until MacroMedia can update its proprietary interface
>> code an then combine this with other CFMX maintenance releases?
>>
>> If so, this sounds like a very poor environment to deploy production
>> web
>> sites.
>>
>> Thoughts?
>>
>> Dick
>>
>>
>
______________________________________________________________________
Your ad could be here. Monies from ads go to support these lists and provide more
resources for the community. http://www.fusionauthority.com/ads.cfm
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
