An interesting experiment with JSON, Postgres and Omnis

Thu Jan 12 19:45:48 EST 2017

I had overlooked this post of Cliffords :)

I find myself nodding in agreement with just about everything stated
here and it is very much why we're looking at doing our web and mobile
development outside of Omnis.

In contrast to Clifford we aren't going down the path of replacing Omnis
with something else feeling Omnis is still the tool of choice for us for
our desktop offering.
We're just looking into strategies to get the best of both worlds that
allow us to keep our investment in our desktop application going while
also adding the mobile and web offering our clients have been asking for.

There is however one point where I think many Omnis developers should
carefully think whether Cliffords words apply to them or whether Omnis
is still the tool of choice.

I do not write off Omnis' efforts where the javascript client is
concerned. As a tool for developing a web application I don't see much
point, there are far better solutions as Clifford has outlines that you
can learn, get proficient in and get a finished product in less time
then it would take you to build a framework in Omnis. And in doing so
you piggy back on the backs of thousands of developers who've dealt with
the many safety issues involved with an online offering.

But if you need a straight forward mobile add on to your existing Omnis
application the cost of deploying the Omnis server is easily outweighed
by the time saved learning and developing in another environment even if
this means you write a separate Omnis application to deploy as a server
application next to your existing desktop app.

While we will likely go down a different technological path for our
mobile solution for various reasons I think there are a lot of Omnis
developers out there whose mobile needs are easily met with the
javascript client and I wouldn't discard it offhand.

And just in case anyone is wondering, we haven't picked our mobile
solution yet and are still trying out things but this little beauty so
far has been at the top of my short list for awhile:
https://www.fusetools.com/

Cheers,

Bas

On 13/01/2017 9:56 AM, Mike Matthews wrote:
> Hello Clifford.
>
> An excellent response of thoughts and ideas.  It catches almost where Lineal is now.  So this very much helps us in our final choice of direction over the next 10 years.
>
> Very much appreciated.
>
> Mike
>
>
>
> Sent from my iPad
>
>>> On 12 Jan 2017, at 06:18, CLIFFORD ILKAY <clifford_ilkay at dinamis.com> wrote:
>>>
>>> On 11/01/17 06:42 AM, Andrea Zen wrote:
>>> Nice share, thanks!
>>>
>>> Just a question: if I understood well, at the moment you have a client-server application entirely written in Omnis and you plan to develop a middle tier that will handle all the business logic with another language.
>>> Why don't you use Omnis also to develop the middle tier? If so you could use the current business logic you have, calling it from remote tasks. From outside you could directly call the $construct of the remote tasks with http calls.
>>> You'll need only to develop the JSON encode/decode part, to format the input as your current business logic expects it, and to format the output in a common understandable way for all possible callers (client/app/web).
>> Hi Andrea,
>>
>> I can answer your question of why not use Omnis for the middle tier from my perspective. There were a few factors that pushed us to use another language for migrating our legacy fat-client Omnis application to a modern, web application.
>>
>> 1. The Omnis Studio application server is a pain to deploy and administer. We use Git for revision control, Jenkins for build and test automation, Packer to build virtual machine images that target VirtualBox, VMWare, Hyper-V, AWS, and Azure. We built an exception notification, tracking, and analysis application that replicates exceptions thrown within the virtual machines to a centralized CouchDB server, and use SaltStack for configuration management within those virtual machines. Attempting to use Omnis Studio in that technology stack is like trying to force a square peg into a round hole.
>>
>> 2. The Omnis application server is not viable on Linux and any further development that is done by engineering to that end is wasted since the monolithic architecture of Omnis is fundamentally at odds with Linux. Having to deploy a GUI or a virtual frame buffer to support Omnis is one example of a non-starter. Even Microsoft has figured out that having a GUI on a server, aside from the image size and being completely unnecessary, poses a greater attack surface. Server 2016 has containers that are an impressively svelte 120M or so because they have no GUI installed and don't support any 32 bit code.
>>
>> 3. Omnis on Linux was, at best, beta software when I used it. I'm past the point of caring to check if that is still the case. At the time, things that were supposed to work, like the MySQL DAM, didn't work two years after it had been released and required custom builds from engineering to get it working, never mind the daily mysterious and non-deterministic freezes of the Studio app server which we "fixed" by using a cron job to restart the app server every four hours.
>>
>> 4. It would have taken as much work to rewrite all our fat-client Omnis windows as JS forms or ultra-thin as it would to switch to a modern web framework since there is no easy way, even with a well-written fat-client Omnis application, to reuse those windows or the business logic. Our application started life on Omnis 7 and it was successfully converted to Studio at great expense using the VDA conversion service. There is no such conversion tool for automating "webifying" a fat-client application and spending a few hundred thousand dollars again to migrate from Omnis to Omnis is, from our perspective, throwing good money after bad when that same money goes a long ways to migrating permanently out of Omnis.
>>
>> 5. Omnis is not a framework. When I compare it with something like Django, a web framework that I have been using for about 10 years, it comes up short. For Omnis to be a viable web development tool, you'd have to implement something like Django first and probably do a poor job of it because Django now has a decade of development with thousands of contributors and the benefit of the collective experience of hundreds of thousands of developers and some of the busiest sites on the Internet behind it. Django is certainly not the only game in town. There are perfectly viable web frameworks in other languages, too, in JavaScript (we use StrongLoop, a Node.js framework), Go, Swift, Ruby, Scala, Clojure, Elm, Elixir, C#, Java, you name it. The thing they have in common is that they all have capabilities that Omnis doesn't have, like templating engines, pluggable authentication, integration with the native logging and daemon manager, ORMs (Object Relational Mappers), and no licensing fees. None of them require one to use a proprietary and anachronistic revision control system or IDE. I think one would be better off to use anything but Omnis for web applications.
>>
>> 6. One cannot build Omnis web applications without being mindful of the deployment licensing costs. It is silly to make application architectural decisions based on the business model of another party (the vendor of Omnis), particularly when Omnis offers no advantage over a myriad of free (in every sense of the word) software options. I wouldn't pick Omnis for a web application even if it were free so that it isn't is only another strike against it.
>>
>> 7. It is challenging enough to find good developers that I don't want to restrict the field to maybe a couple dozen developers globally who know how to build modern web applications using Omnis and are available for hire. Hiring people who don't know Omnis and training them isn't worth the effort when that same person could be productive much more quickly with a language that is more mainstream, like JavaScript, Python, Ruby, etc. From a young developer's perspective, gaining experience on a complex business application using AngularJS and Node.js is much better for their career than gaining experience with Omnis, a tool most people have never heard of. You could make the argument that the language in which a vertical market application should not matter to the users of that application and I could buy into it, though I think it's more complicated than that. The implementation language matters to developers and aside from the people on this list, developers have not been buying what Omnis has been selling for a long time. In short, someone who isn't already using Omnis isn't likely to adopt it because it has no advantage over other languages or frameworks for web applications and plenty of disadvantages.
>>
>> 8. We were concerned about the viability of Omnis as a business entity. I think you're one of the new owners and if so, while I wish you all the best, it's not likely that Omnis is going to be the next big thing. This ties in with #7.
>>
>> 9. Omnis is blocking and doesn't take advantage of multiple cores. Node.js is non-blocking so we can continue servicing new requests without having to wait for a previous request to have been fulfilled by using callbacks or preferably, promises. We automatically start as many Node.js app servers as there are CPU cores without having to give any thought to licensing costs. (See #6.)
>>
>> 10. Our legacy Omnis application only used the native datafile at the outset. At some point, we started supporting MS SQL Server. Our AngularJS/StrongLoop/Node.js application goes against the same SQL Server database as the legacy Omnis application. Additionally, we use PostgreSQL and CouchDB. I know there is a PG DAM for Omnis but it's not quite as straightforward for us to support PG from Omnis as just installing the DAM and setting up a connection because due to the lack of an abstraction layer in Omnis for backends (no ORM), much of the SQL is very SQL Server specific. In our web application, it was a trivial matter to support those completely disparate backends, one of which isn't even a SQL database simply by configuration. In fact, we've modified the SQL Server connector in StrongLoop to make some optimizations because we have the source code. That just isn't possible with Omnis.
>>
>> Anyone who has read this far may be wondering how the fat-client Omnis application and the AngularJS/Node.js web application that go against the same database ensure that there is only one source of truth about the data model. That part is actually quite easy. The legacy Omnis application has a custom-built schema migration utility because, again, Omnis is not a framework so it does not have such a capability out of the box. What we have now is a hybrid fat-client and web application. The custom-built schema migration utility generates the DDL based on the Omnis file classes. That DDL is applied against the SQL Server database. We run a script that inspects the database and generates the JavaScript classes that StrongLoop uses. When Omnis is no longer in the picture, all we have to do is flip a schema migration configuration parameter in StrongLoop from False to True.
>>
>> Additionally, the legacy application and web application are integrated and appear to be one application by virtue of a custom XCOMP we've built using the Chromium Embedded Framework. In essence, we have an Omnis window, wBrowser, which contains the CEF browser object. If the Omnis window has already been converted to an AngularJS form, Omnis invokes wBrowser, and passes a URL to the browser object. The browser object renders the output of the AngularJS application as it would render any other HTML/CSS/JavaScript. Behind the scenes, AngularJS may be hitting a handful of API endpoints to get the data it needs for the current web form. If the user takes an action on the web form that has to open an Omnis fat-client window, JavaScript calls back into a dispatcher in Omnis and passes any relevant parameters. The web application is deployed within a virtual machine which may or may not be in the same location as the fat-client Omnis application. It's never on the same machine. We can pass parameters back and forth between JavaScript and Omnis easily. You can think of this as inter-process communication between code that is running on different memory spaces that happen to be on completely different machines.
>>
>> The only way that users may be able to tell that they're looking at a web form vs a fat-client window is that the look and feel isn't exactly the same. We may have been able to use the Omnis icons in the web application but we had two concerns with that. The first is that we intend to migrate away from Omnis so we don't want to deal with any copyright issues on the icons when we're no longer using Omnis. The second is that the Omnis icons looked good when Windows 98 was considered modern. They look dated and ugly today. We have been careful to not change the look and feel of the web forms very much to eliminate the need for retraining of users. Once we've factored Omnis out of the picture, we can evolve the look and feel of the web application so that it looks more modern. That's easy to do with CSS.
>>
>> While this would be a great way to incrementally get out of Omnis, which is our intention, it need not be the end goal. There are use cases for hybrid fat-client and web applications, though I think it's only a matter of time before there is no distinction between fat-client and web applications. The performance of the web application is better than Omnis in some cases and never worse. For us, this hybrid approach enables us to migrate out of Omnis while the Omnis application is still being used.
>>
>> 10. One of the common exit strategies for a VAR is to sell the company. Omnis is a detriment to the valuation of the VAR's company for all the reasons listed above. In any conversation with a prospective buyer, no one is going to question our sanity in using an application stack that is used by millions of developers and powers some of the busiest web applications in the world. We don't want to have to sell a prospective buyer on the merits of Omnis because it could call into question our judgment for picking such an obscure technology. What we've chosen is a safe bet and certainly isn't going to detract from the valuation of the company and in all likelihood, it will enhance it, especially when there is no runtime deployment costs. Runtime deployment costs might have been defensible for fat-client applications but it isn't for web applications.
>>
>> -- 
>> Regards,
>>
>> Clifford Ilkay
>>
>> + 1 647-778-8696
>>
>>
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
>
>
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
>
>

-- 
Kindest Regards,

Bastiaan Olij
e-mail: bastiaan at basenlily.me
web: http://www.basenlily.me
Skype: Mux213
http://www.linkedin.com/in/bastiaanolij