A New Week, A New ColdFusion 8 Wishlist

I've broken my list down into three major areas: Enterprise (Platform-level), Developer-level, and Language-level. Further, not every wish below are ones that I'd personally like to see, but I believe they're all worth discussing at some level. Lastly, they are in no particular order. I know it's a really long list, but a major release shouldn't just be about fixes; it needs to innovate and that's what I think certain items below allow the user to do. Hence the long, detailed list with lot of explanatory text for each point.

Enterprise (Platform-level)

• Serializable CFCs: Come on, it's time to leap that last technical hurdle (I think it was either WebSphere or WebLogic that was the obstacle to getting this in CF 7) and make my cluster life easier. I'm sick of my workaround for a basic enterprise feature.
• Allow logging to be done to one location rather than forcing to cfusion/logs: This one's important to me as a developer who works in a clustered environment. Being forced to write to the cfusion/logs directory is annoying because I then have to guess which server just served a request by looking at the timestamps. As you add more instances to the cluster, the more of a hassle this becomes.
• Better integration with Word and Excel file formats: Regardless of how you feel about Microsoft, their format is the de facto standard in virtually all enterprise organizations. Writing Word and Excel documents (including charts, etc.) would be immensely helpful. We use a product called e.Spreadsheet by Actuate for our XLS reporting needs, and it's a pure Java solution that supports all but 2 extremely obscure Excels features. It has matrices, charting, pivot tables, in addition to formulas. So this is definitely technically possible to accomplish and could be a very compelling feature for an enterprise.
• Better management of whitespace: I've never understood why ColdFusion stinks with whitespace suppression. On the one hand I recognize the argument that it can be tricky to determine what is and is not intended whitespace, but other languages don't have this problem, so clearly this must be solvable. We use (sort of) Empirix's e-Test Suite for our functional and load testing needs. However, cleaning up whitespace technically causes regression test failures. Now, I'm not saying this should be solved because one product has problems with it, but I just don't see any need to keep whitespace around in the generate HTML source.
• Upgrade Web Services Engine to Axis2: Of all the wishlists I've seen, I have to say I'm a bit surprised I didn't see more in the way of web services enhancements. Axis2 supports REST, which I personally prefer to SOAP, as it's unbelievably easier to work with. Also, it has better support for true web services security, which is a solution I desperately need. Appending a user name and password to the WSDL URL doesn't cut it. Introduce formal features for both of those and I'm a much happier person.
• LiveCycle Integration: I'm still getting a feel for what exactly LiveCycle does and doesn't do, but I would wager that most organizations have some sort of document flow process that could stand to be better managed. LiveCycle, from what I can tell, does this. I'd love to be able to integrate an enterprise-level document flow system into my company's practices, and the ease with which CF could potentially offer that is intriguing. I'm still thinking through this one a bit though.
• Better search capabilities for clustered environments: OK, I know that Tom Jordahl and others worked their tails off on upgrading the Verity engine for the CF 7 release, and the new features look incredible. But I can't use them because I'm in a clustered environment and there are no provisions for properly managing the collections across the servers (I think it's licensing or something). I like searching. I need searching. I can't use what's currently there, and I'd prefer to stay away from a database-centric solution or pay $100,000+ for a modest solution.
• Essentially, Fusion Reactor or SeeFusion: This one I know is being worked on because Adobe's been pretty open about it, but it really needs to be a home run. Lack of metrics and insight into CF instances are the bane of many developers' lives. I hope that Adobe follows Integral's lead by providing incredibly helpful visual indications and graphs so that I can get a feel for what's going on by literally glancing at my monitor.
• Plug-in based architecture to turn off Verity, Flash Forms, etc. OK, let's face it -- lots of deployments don't use certain "add-ons" to ColdFusion, such as Verity, Flash Forms, and Reporting. Whether it be the inadequacy of the existing feature set or the reliance on a previously-existing infrastructure, the aforementioned features are loaded on each and every re-boot of the server instance, taking up valuable resources. I'd like the ability to turn on and off (via the CF Administrator or Admin API) pieces of the CF runtime. The floodgates were opened when Event Gateways were allowed to be turned on and off, so it should be technically possible to achieve. I'd like to see this extended to the other plug-gable features so that I can reduce the memory footprint. I think hosting providers in particular would use this feature.
• Full admin API hooks to everything CF Administrator offers: The CF Admin API that shipped with CF 7 was great, but I'd like to see a one-for-one match in the offered features. This would be immensely convenient for vendors who want to package up an application but provide their own interface to the configuration settings.
• Role-based CF Administrator: I think this one is long overdue. Your security is only as strong as its weakest link. If one were to get the password to a CF Administrator, there's way too much that can be done by default. A basic roles-based login enhancement so that certain areas (i.e., datasources) can be locked down while other less-hurtful settings (i.e., debugging settings) can be accessed by anybody would be incredibly useful.
• Enhance the report engine: It's too easy to point out the various bugs that people have reported with regard to the Reporting engine in CF 7. It was a first attempt, and it was to be expected that there would be problems. However, the "intro period" is over. I'd like to see a robust reporting engine implemented that will allow me to include complex charts and graphs and page breaks.
• 64-bit and JDK 1.5 support: Damon already posted in one of my previous entries that Scorpio has JDK 1.5 support, but it's not out yet so I'm listing it! ;) As for 64-bit support, I'd like to see a pure 64-bit kit available so that I can take advantage of the larger per-instance memory spaces that 64-bit platforms allow.
• .NET Runtime: This one is sure to draw the ire of many, and still others will make the point that "New Atlanta does this with BlueDragon already, so why waste our time." Here's the thing though. It has been reported recently that .NET has surpassed Java as the development platform of choice. I personally don't think that's accurate at all, but there's no denying that .NET has made significant inroads. Why not offer the ability to deploy on both of the major enterprise platforms? It can only increase ColdFusion's exposure while opening up new sales channels for the product.

Developer-level

• CFDoc: This is my second biggest enhancement request for CFCs (serializing them being my biggest). Documentation is so critical to any project. But this documentation doesn't always have to be a Word document with use cases and "business-speak." Just as important is the API documentation, and let's face it, the hint attribute just doesn't cut it. I'd like to see a proper Javadoc/ASDoc implementation for ColdFusion so that I'm not confined to just a phrase or two. If you provide a more robust solution for documentation, I'd wager you'll see more robust developer documentation.
• IDE overhaul: This one's a biggie and is likely a whole separate development cycle, but I had to throw this one in here. Mark Drew has done a phenomenal job of taking over the CFEclipse effort. But the reality is that his efforts and the efforts of many others who have contributed to the project all come in their spare time. That is neither fair to them nor to the CF development community who are essentially at their mercy when it comes to bug fixes (and yes, there are bugs). It's been over a year since the last official, stable release. ColdFusion needs a professional IDE. I have been working with Flex 2 lately, and it's downright appalling to see the level of professional polish on the Flex Builder IDE versus the CFEclipse IDE. That's not to be taken as a shot at Mark et al. Rather, it's just a recognition that I am immensely more productive in the Flex Builder IDE than I am in the CFEclipse IDE. Flex is about 2 years old and ColdFusion is 11 years old, and Flex development productivity blows away ColdFusion development productivity. That's a shame and I hope that Adobe finds the resources to dedicate a team of developers who can polish up CFEclipse by providing me more than RDS support, for which I have zero need. Things like CFC introspection and recognition that I didn't properly var scope a variable are much more useful.

Language-level

• Concept of null: First and foremost, I'm not necessarily talking about being able to type null itself. I recognize that the underlying engine would need a serious overhaul to be able to support it. However, I need to be able to declare a cfargument as a type of numeric, yet still have the option of not passing a value in without having to default to 0. In a lot of the work that I do, zero has a very real meaning and it can't be used as a conditional check to see if a numeric value is valid. Further, I shouldn't have to switch the datatype and use a string instead because that's not the correct self-documentation of what that argument is.
• Re-do Flash Forms: One thing that I noticed at CFUNITED was how even the Adobe employees were making fun of Flex 1.5 because of how hard it was to do things relative to Flex 2. Flash Forms, in their current incarnation, just don't cut it. It's a "cute" feature without any real-world possibility of implementing. I vote that it be entirely overhauled and that the Flex 2 engine is embedded. Then you can wheel and deal with some incredible user interfaces while providing the ease of use that we have come to know with ColdFusion. For backwards compatibility, if it can't just be upgraded without touching anything, I would suggest that there be a toggle switch between 1.5 and 2 to maintain backwards compatibility (i.e., a version attribute) so that existing implementations won't break.
• Spry integration: Spry isn't quite ready for production just yet (nor is it presented that way), but it's a compelling alternative to Flash-based interfaces. The current ability to create an accordion interface is just a small part of its potential as not only an interactive data bus but a viable UI alternative to both "conventional" HTML and Flash.
• Interfaces: Yep, I'm saying it. I'd like to see interfaces. Does ColdFusion need them? Nope. Did ColdFusion need CFCs? Nope. I both built and saw some pretty complex applications pre-MX, and I could have continued to develop in that paradigm if I wanted to. But CFCs became compelling because they allowed to me to do my work in a more efficient, cleaner way. In my opinion, interfaces offer me this potential as well, as they allow a system architect to "stub" a domain model and leave it to the developers to implement the details. Now, don't misunderstand, I'm not meaning to suggest that introducing interfaces will be as significant as introducing CFCs. And I'm sorry, I just don't buy the argument that somehow introducing interfaces makes ColdFusion harder to develop with. First off, it's optional and second, it's truly gives you the power to "develop to an interface, not an implementation." Perhaps a new file type of .cfi could be introduced to allow an application architect to specify the method signatures, while also introducing an attribute to cfcomponent called implements, which allows users to specify multiple .cfi classes.
• Deprecate cfscript: Don't remove it, just formally acknowledge that the engineers are not going to be doing anything more with it. I was a big cfscript fan for a long time, but I was sick of having to have a hybrid codebase of script-based logic wrapped by tag-based features such as cflock or some such because they can't (natively) be called within a cfscript block.
• Add stream-based file read/write functions to support large files: The "read the whole file into memory before being able to do anything with it" is antiquated. I don't know what the old underlying C options were (the language that pre-CFMX was written in), but Java offers some robust options for reading and writing large files by streaming. This is a must-have, and I think the increased traffic recently on the mailing lists is indicative of this.
• IMAP support: Let me see... there's POP, FTP, HTTP, SMS, and XMPP support, but no IMAP support? Come on, let's get this done.
• Add a function to distinguish between createObject() and createCFC(): FUD or not, shared hosts are a pain with this. My host (HostMySite) is not, but there are many who lock down createObject and cfobject from being used (thereby preventing CFC usage) because it provides access to the underlying Java API, which could theoretically allow malicious activities and/or suck up system resources. I'm not sure how much I buy that (it's possible to do it in other ways too that aren't locked down), but the ability to distinguish between calling Java objects vs. non-Java objects at the tag-level would be valuable and helpful.
• For the CF tags that generate markup, support the ability to validate generated markup using a specified doctype: A long-time pet peeve of mine. If I'm going to spend the time to make my markup compliant to a certain validation level, don't hamstring me by outputting non-compliant code. Add an attribute to each affected tag called markup that takes values like "xhmtl" or "html4" (i.e., cfchart markup="xhtml").
• Ability to throw objects rather than strings: I've come across this particular obstacle recently and I often find myself wishing that I could throw an object using cfthrow rather than just a string. This would allow communication between the calling and target code to be a bit smoother rather than having to write workarounds for getting the appropriate information back.
• Add a trace() function that allows you to dump an object during execution: This one's straight out of the ModelGlue framework, but there's a super handy function in there called trace() that allows you to dump out any object during page execution and have it displayed in the debugging info at the bottom of the page. This allows you to see the evolution of a variable throughout the whole page rather than having to do a cfdump/cfabort in broken steps.
• Take the most popular cflib UDFs and make them native: This is just a convenience. I would think that Ray and Rob have stats on the "most downloaded UDFs" or "most popular UDFs." Just make our lives easier and make the top 20 or so native.
• Syndication: I know that there are those who are calling for a RSS tag, and quite frankly, I don't think the end-user cares if the feed is RSS or Atom as long as they get the right content. However, an interesting blog entry I read recently got me thinking that maybe Atom is the better selection. That being said, some sort of RSS/Atom feature needs to be added to account for the major browsers offering the consumption of these feeds natively.
• Full i18n features to please Paul Hastings, and the non-English speaking world: This is so crucial in today's world that I'll just point to Paul's recent posting to outline what needs to be fixed.
• CFImage: Eleven years in and ColdFusion doesn't have anything built-in to it to really work with images on any sort of useful level. I know that some will point out that Java can do this natively, but the point of ColdFusion is to "Make Hard Stuff Easy," and I don't think developers should be forced to use the Java API just to get some basic functionality.

I'm sure there are some features that I've left out, but, quite frankly, they don't come to mind, so how important can they really be!

Go ahead, fire back!