The tests are of basic language constructs that offer no benefit of being different. It's as if one engine decided to rename the "this" scope to "that" because they prefered the word "that". What would be the point? I think it only helps everyone for the *basic* language to be as compatible as possible between engines. If someone had a simple app consisting of queries and display, they would expect to be able to drop it in any engine and have it work. OpenBD is already 90%+ compatible - why the resistence for a bit more? It is a CFML engine and should adhere to CFML standards, otherwise just name it OBDML.
Where the engines should differentiate, is with added value integrations such as: - Amazon Web Services - Verity/Lucene searching - Ajax - Hibernate - etc. OpenBD will be king of the cloud. Railo will be for that obscure integration that someone is selling as an add-on for 100 bucks. And CF is CF. I can forsee situations where someone runs 2 engines on the same box because using the built-in features that each engine is good would save lots of time. But that won't happen if the engines don't get the basic CFML right. To answer some previous statements: > The vast majority of people in my experience, rarely move engines once > development has started Where are all your users coming from then :-) and the only people that really seem to care > are the ones building the standard frameworks > True, but users care about being able to run their frameworks. If a framework can't get their code to work, or doesn't have time to manage the differences, then users of that framework just won't use that engine. Baz On Wed, Apr 29, 2009 at 3:55 PM, Sean Corfield <[email protected]>wrote: > > On Wed, Apr 29, 2009 at 4:08 AM, Alan Williamson <[email protected]> > wrote: > > *if* all CFML engines were ____FREE____ then yes, this would be a > > perfect analogy and yes, there would be a huge drive to then make things > > as compatible as possible. > > In the C++ world, it didn't matter that some compilers were free and > some were commercial offerings - compatibility to a written standard > was the important goal. > > In theory, the specification produced by the CFML Advisory Committee > will (eventually) be detailed enough to cover this sort of thing and > Brett's test suite could test against the specification, rather than > any vendor's documentation. The specification is, after all, intended > to be something agreed by the vendors and the community. > > The first version of the specification - CFML2009, coming this summer > we hope - will not be detailed enough to covers some specifics > (because it's just more work than we can possibly get done) but it > will provide a seed document that we can elaborate on over time, > highlighting inconsistencies and deciding what the official "core > language" behavior should be. > -- > Sean A Corfield -- (904) 302-SEAN > CTO, Railo US -- http://getrailo.com/ > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > > --~--~---------~--~----~------------~-------~--~----~ Open BlueDragon Public Mailing List http://groups.google.com/group/openbd?hl=en official site @ http://www.openbluedragon.org/ !! save a network - trim replies before posting !! -~----------~----~----~----~------~----~------~--~---
