On Wed, May 19, 2010 at 1:36 PM, Jason King <[email protected]> wrote:
> How hard would it be to write an app to search a folder of .cfm code to > look for incompatabilities? And if one is found, solutions could be > recommended? Harder and a lot more time-consuming than dropping the app on OpenBD and addressing the issues that show up, if there are any. Not to mention you'd constantly be updating the auditing application as new things are added to OpenBD. The problem with writing a code auditing app is people can write code in a million different ways, and when you get into syntax issues it gets messy very quickly. It's almost as if you'd be rewriting the parser so you could test for syntax compatibility, at which point why not just fire up the app and see what breaks. You could do the big ones easily, sure, but writing something that would "certify" the code to be compatible with OpenBD would be a huge effort and seems rather unnecessary to me since unless you're using known CF-only features, the code will likely run fine. This is also where unit/functional testing comes in. If an app has tests that can be run at the push of a button, then of course the code could be dropped into OpenBD and the tests could be run to see if any issues arise. > > We host a lot of cfml customers and we'd like to pitch moving them to > OpenBD. I just don't see us having the time to audit all of their code.. > Personally I think the concern is the abstract is greatly exaggerated as compared to the reality of the situation. I've moved a LOT of apps from CF 8 to OpenBD in the last couple of years and have run into very few issues, and any issues I had early on have been resolved by the latest release of OpenBD. Particularly with the enhancements to the scripting engine in OpenBD 1.3, the majority of the older gotchas like using the ++ operator, etc. no longer exist. Maybe I'm overestimating the amount of work that would be involved with writing a code auditor, but even with that in place there really is no substitute for testing the application on OpenBD, and chances are the developers of the application being moved would be able to glance at the compatibility section of the wiki (which could probably use some updating at this point) and be able to tell pretty easily if they'll run into any issues. I'd be curious to hear everyone's thoughts on this, but it seems to me to be a massive effort with not a lot of payoff since at the end of the day it would only be able to say, "Yeah, we didn't find any known compatibility issues" and would be no substitute for unit/functional testing anyway. -- Matthew Woodward [email protected] http://blog.mattwoodward.com identi.ca/Twitter: @mpwoodward Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments. http://www.gnu.org/philosophy/no-word-attachments.html -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon mailing list - http://groups.google.com/group/openbd?hl=en !! save a network - please trim replies before posting !!
