It may be a bit early, but I have a New Year's resolution I'd like to propose to Sybase: "No more 80% solutions."

What is an 80% solution? It's a technology approach that seems well conceived and when used with small demonstration applications (e.g., beta testing) works well. However, when the product is released and people begin using it in earnest to develop larger "real-world" applications, they end up hitting walls. The walls were always there. However, because the people involved in testing it weren't trying to actually develop "real-world" applications with it during the testing phase, the walls weren't discovered and addressed during the development of the technology. Or perhaps they were even surfaced by individual beta testers, but they never reached critical mass because not enough people recognized the looming problem.

Those 80% solutions also tend to remain 80% solutions because the development effort, particularly for new product versions, is more focused on providing new features than completing the implementation of existing ones. Unfortunately, that mind set is often encouraged if there are workarounds for the missing functionality, even if it requires a great deal of work or third-party utilities to implement something that really should have been part of the initial functionality. Instead, what we get is a new crop of 80% solutions.

Then in the worse case, the technology or feature is eventually dropped because it didn't gain a great enough adoption rate to warrant continued support. An adoption rate it might have enjoyed if the functionality had ever been implemented beyond the 80% level.

When PowerBuilder was originally being developed, the beta testing was done by people who were actively trying to use the product to produce production applications with it. The companies involved were much more highly invested in the outcome of the initial release, and any walls that might have existed in the implementation were flushed out before the product was released. In addition, PowerBuilder was used internally to create and maintain corporate applications, which meant that walls in the implemented functionality would be experienced firsthand by members of the development staff.

Part of the recommended solution to eliminate future 80% solutions is a change to the way that the initial development and testing of new features is managed to ensure that the testing that is done more adequately resembles "real-world" application development.

The other part of the recommended solution is to go back and address some of the existing 80% solutions. My list would include the following.

PocketBuilder
Open up support for databases other than ASA. I'm not knocking ASA; I love the product. But we're seeing a repeat of the "PowerBuilder will deploy to any app server as long as it's EAServer" mentality. If ASA is a better product than Microsoft's SQL Server CE / Mobile Edition (and I believe it is), then it will stand on its own merits. All that's accomplished by limiting connectivity to ASA is to eliminate the product for consideration by folks who don't have a choice but to develop against Microsoft SQL Server CE / Mobile Edition.

DataWindow.NET
Eliminate the need to put unmanaged DLLs in the system path. Most Web site hosting services either don't allow such high-privilege modifications to the server or require the use of a much higher-priced (e.g., dedicated server) option before they allow it. Most Web administrators in large corporations take a similar approach to their production Web servers. The vast majority of the production Web servers I have to deploy to won't even let me create registry entries in the HKEY_LOCAL_MACHINE store during the software install! The only way to allow for any significant market penetration is to eliminate roadblocks to the deployment of the code. Nobody's going to be interested in a product that works great on the developer's machine but can't be deployed.

PowerBuilder Complete the DOM/PBSAX functionality. We were given PBDOM in PB9, but there's never been an equivalent PBSAX parser. For handling large documents and for speed, SAX is often a better alternative than DOM. While you're at it, there should be some way to get the XML back out of a PBDOM_DOCUMENT without having to save it to an intermediate file first.

Allow importing of nested XML. The DataWindow currently supports XML exporting of nested reports, which can generate a highly structured document. However, when it comes to importing, we're basically still stuck with a flat structure. If you have multiple levels in an XML document you need to import, you currently need to use a DOM parser to read it and manually populate individual DataWindows for each of the levels.

Add a treeview style DataWindow that supports dynamic retrieval. The current DataWindow treeview presentation style is fine so long as you can retrieve all of the data (including all levels) from a single SQL statement and you don't mind having to retrieve the entire result set prior to displaying any of the data. It's not useful for displaying highly complex data or large amounts of data where the user might need to navigate only through a small subset (but be able to do so dynamically). What we need in such cases is something similar to the PFC treeview data service, where a different DataWindow source can be used for each layer in the treeview, and the retrieval of the results can be delayed until the user actually wants to expand a particular leaf.

Deliver on the plug-in API documentation. When PB9 introduced the PowerDesigner plug-in for PowerBuilder, there was an indication that the plug-in API would be documented later so that other plug-ins could be developed by third parties. We're coming up on the third major release since then with no documentation in sight.

Keep up with Web services standards. The .NET engine has really helped with compatibility with newer Web services and addressed a number of deficiencies with the EasySOAP implementation, particularly with regard to authentication. However, some Web services require custom headers for authentication, something that even the .NET engine doesn't support because it doesn't give us access to the envelope. In addition, the .NET engine only supports the SOAP protocol. The REST protocol is becoming at least as popular as the SOAP protocol for implementing Web services, and we need a method that supports that protocol as well.

MAPI is so 1990s. Since most clients are probably using Outlook, the Outlook security enhancements have pretty much rendered MAPI useless as a means of sending e-mail from an application. It's also not particularly appropriate for applications that might be running as a service (i.e., under a SYSTEM account rather than a user account). Finally, it's not capable of supporting features that users are expecting in modern e-mail, such as HTML formatting of the message body. Let's have some alternatives for sending e-mail, particularly SMTP. (I'm pretty much contradicting some of my recent statements in the Sybase newsgroups where I argue this should be left to third-party add-ins, including some I've developed and made available on CodeXchange. I guess the bottom line is that I'm quite comfortable using a third-party approach - particularly my own - but recognize that a significant body of customers isn't quite as comfortable with that approach).

Allow arrays of structures as returns from functions. Why is this a big deal? Because if you're going to try to return a result set from a PowerBuilder-based Web service and you want your Web service to be able to interoperate with other development tools, you'llto need to return arrays of structures and nested structures. Right now about the closest you can get is to return an XML string and then try to manually manipulate the WSDL to let the clients know what the structure really is.

That's my initial list. I'd be interested in hearing what items you think I may have missed.