OK Chris et Al
Much more of a conceptual presentation than before, showing the deployment options that we would all like to see in an ideal world.
I was particularly pleased to see the inclusion of ADP for data transport creating a uniform method of talking to remote objects and databases, this I can see adding huge value to the development proposition and at the same time allowing an easier transition for developers with large n-tier application based on EAServer. This would also allow developers to easily thin down their clients in the traditional fat desktop applications.
The Deployment architectures all make sense and are quite exciting for some of our existing PB applications. Particularly those that are typically used by small business and so are deployed to many customers. The OTA deployment would be perfect with back-end server deployment to a cloud or hosted solution if that is what they would like. Not always practical when you are based in the highlands of Scotland and have a very intermittent internet connection. You need your system local in order to maintain the business service. So we need to option for both deployment strategies.
For us mobile is still only a small consideration as the majority of the business applications will still be based on windows pc clients. Despite what Armeen said I believe there is now a shift away from people installing apps to interact with businesses on-line. Unless you are going to regularly use that supplier it is quite irritating to have to install an app in order to perform a single transaction. The number of installed apps a user has is declining, we now expect the html web sites to have high functionality specifically designed for the mobile device. Nowhere in this vision is a solution for that.
In my opinion the priority should be the desktop application, yes we need to understand the end goal and how we are to get there. But the first step on that road should be to bring the desktop application development tool up to the level described with the n-tier deployment options and OTA delivery. The second phase can be to address the deploy anywhere and mobile deployments.
Finally there is still no credible solution for developing highly functional HTML5 applications. This is not a specific PB issue, but a wider development tools issue. All the tools I have looked at fall far short of being an appropriate RAD tool for HTML5. I believe that PB has the right underlying concepts, linked with the skills that Appeon have, to provide a HTML5 RAD tool. I do not expect this tool to be a migration for PB but just use the building blocks and powerscript language as the core of the IDE. Perhaps this could be phase 3 of the Appeon vision?
Going back to the Appeon presentation, I'm still concerned by the HOW? I was less than impressed by the concept of PB being a plug-in to Visual Studio, I believe that would be the final nail in the coffin for PB. For PB to survive and stand up on it's own we need our own specialist IDE. If you move PB to VS then what is the point in developing new apps in PB, the IT strategy will undoubtedly be to write new code in c# only and not to use any PB objects so as to break free from that "legacy" platform. Not my point of view you understand but CTO's will still want to get rid of PB seeing it as a small wart on the side of the wonderful VS offering. By having our own IDE and demonstrating the power of the language and its deployment options will make PB stand out rather than be merged in. By standing away from the crowd we will shine again and CTO's will look at PB as a viable strategy decision.
That's my 2p worth.
David