Now that PowerBuilder 2019 and its new C# development capabilities are in beta, we are starting to get questions about the future of PowerScript desktop apps. Specifically, does Appeon recommend developers to move away from PowerScript desktop apps? And related to this point, will Appeon be enhancing or just maintaining the features of PowerScript desktop apps?
A quick look at the PowerBuilder roadmap page and it is obvious we have put much focus on the C# language, open standards, and cloud architecture. Increasingly, most new .NET projects have such high-level requirements. Perhaps this is why the .NET framework is radically different these days – the .NET Core framework is open source, cross OS, and targeted for cloud deployment. And unfortunately, we could not use any of the .NET stuff Sybase did because it didn’t meet these requirements. So certainly, we had to put a lot of focus on non-client/server features.
Now let’s assume for the sake of argument that the cloud is the future and focus on if and how a PowerScript desktop app fits into such future. A native UI technology (e.g. PowerScript desktop app) has certain advantages over HTML (e.g. ASP.NET page) and vice versa. However, for most line-of-business apps we believe a native UI technology offers the best set of tradeoffs. Key industry players like Microsoft seem to be recognizing the shortcomings of HTML and trying to lessen this gap with Progressive Web Apps (PWAs). At Appeon, we think it makes more sense to “cloudify” the PowerScript desktop app than replace it with some other technology.
In fact, we began to “cloudify” the PowerScript desktop app the second we took over PowerBuilder, which we did on top of its existing C++ runtime and PowerScript language. Starting with PowerBuilder 2017, we introduced an all-purpose HTTP client, a REST-specific client, an OAuth2 client (with support for tokens), and JSON handling (parsing, generating, packaging). And in PowerBuilder 2019, we have significantly enhanced all of these features, especially how they integrate with the DataWindow to minimize the amount of coding you do.
But of course, there is still more work for Appeon to do with the PowerScript desktop app to make it attractive for new projects, no matter they are client/server or cloud based. This is exactly why in every single release for the foreseeable future we have planned to bring major new features to the desktop target. For example, in PowerBuilder 2019 we will revamp the UI of desktop apps. And in PowerBuilder 2021 we plan to revamp deployment of desktop apps (from the cloud). Beyond that, it would be silly of us to say now, and most vendors wouldn’t even say this much.
PowerBuilder’s prowess to be able to enable Win32 and Win64 native applications to directly interact with the Internet universe started when Sybase added the iNet object class to the PowerBuilder System Class area. The iNet object object’s methods allowed native PB apps to link out to a specific URL via the LinkToURL command, send data to a specific URL via the PostURL command and/or read data from a URL via the GetURL command. While this is still in PowerBuilder 2017 R2 for backwards compatibility, its functionality limitations and security vulnerabilities (only supports up to TLS 1.1) definitely makes it worthwhile to explore the new HTTPClient object, which we will discuss in this blog.
Figure 1- iNet object as seen in the PB IDE's Object Browser
In modern-day Internet interactions, applications often require more advanced functionality within their URL processing and support for at least the TLS 1.2 protocol is a must. Thus, starting in PB 2017 R2, Appeon added the HTTPClient object to the PowerBuilder’s System Class area. The HTTPClient object is designed to take over from the iNet object and to provide key advanced features that were requested of the iNet object even way back in the Sybase days of PowerBuilder but were never implemented. Some of these key advanced Internet features requests were to: set Request Header(s), read a Response object’s Header or Body, get the Response Code from a Request, process binary data, handle JSON data, and of course support TLS 1.2.
You may be wondering why Appeon didn’t just enhance the iNet object? One of the key reasons for introducing a new HTTPClient object class rather than revamping the existing iNet object was to avoid iNet object class behavioral changes that could break existing apps when migrating to newer PowerBuilder releases. The other key reason was an entirely new implementation was necessary so that the RESTClient object (covered in another blog) could make use of the HTTPClient. This was important design consideration by Appeon such that PowerBuilder would have a modularized and extensible architecture.
PowerBuilder’s Web Service prowess has increased significantly in recent releases from Appeon - in particular, PB2017 R2 and R3 release. These PowerBuilder releases have given us a new HTTP Client and RESTful Client capabilities that can utilize the newer JSON (JavaScript Object Notation) data format and the ever-popular XML (Extensible Markup Language) data format as well. When processing standard data type information in either the JSON or XML format, the ease of data exchange is very high. However, when trying to transfer binary data, the JSON and XML formats and the supporting HTTP transport layer for RESTful web services will not readily handle binary data.
To address this binary dilemma in the JSON and XML realm, today’s applications utilize the Base64 binary-to-text encoding mechanism to convert binary data into ASCII text sequences of the data. This allows the converted data to be injected into the JSON or XML schema and transmitted without upsetting the HTTP transport protocol. While it does increase the overall transmission data length when utilizing this encoding scheme, it is necessary in order to achieve the end goal of data exchange with these technologies.
In PB2017 R3, PowerBuilder will be updated to include new functions to both encode and decode binary data to and from the Base64 encoding scheme. The new PB built-in Base64Encode and Base64Decode commands can now perform the encoding in and out of the Base64 scheme using the standard PowerBuilder run-time engine support. For example, the PB Base64 PNG image used in this article would look like the following in a hexadecimal editor:
Figure 1- PowerBuilder Base64 Image in Hex
Using the new built-in Base64Encode method, the PNG image binary data is converted into a set of ASCII character sequences which can now be easily transmitted or even read by a simple text editor, as follows: