Desktop apps and Web - what makes sense?

Alain Stouder Omnis omnis at smartway.ch
Wed Aug 11 11:34:47 UTC 2021


I second that reporting in Omnis is not easy to grasp but very powerful once mastered.

A few improvements like a smart report wizard could help to get ppl started.

I’ve used other tools for desktop, mobile and web development but Omnis is a good client/app server once you’ve find the right license/serial agreement.

Like others, I struggled with open source javascript and node.js but it’s part of the web learning curve.

The issue with mobile is that Apple is a PITA with its proprietary and ever changing policies.

Once you have REST servers, you can code the mobile client with whatever you want.

—
Learn something new every day !

> On 11 Aug 2021, at 12:50, Mike Matthews - Omnis <omnis at lineal.co.uk> wrote:
> 
> 
> 
> I do find it interesting that more than one person here has mentioned Omnis for reporting. The Omnis reporting engine is a fickle beast, and works great when you know how to use it. But it confuses our young devs (30 and under) and lacks interactivity and portability. I feel there is opportunity to improve this technology, but the exact path forward isn't completely clear.
> 
> Hello Alex,
> 
> Fickle; now that is a HUGE understatement indeed. :)
> 
> Mike
> 
> 
> 
> 
> 
> Alex
> 
> On Aug 10, 2021, at 19:04, Doug Easterbrook <doug at artsman.com<mailto:doug at artsman.com>> wrote:
> 
> hi Greg.
> 
> almost .
> 
> we put some things int stored procedures and triggers when we need some thing to be fast.  Lets see if I can cite some example for you.
> 
> SQL lets you update many records at one time.  eg update table set field1=10 could do many thousands of records if you don’t supply a where clause.   a stored procedure is not necessary for that.
> 
> on the other hand, if we are looking for available tickets and we want to suggest some for people taking into account proximity to other seats, not leaving single seats as part of an offering to the customer (single seats tend to stay that way, losing people revenue), taking into account seats that are held back until closer to the performance….
> 
> we use a stored procedure for that because simply offering one seat to you means we have to examine many around you, and if thats not right, we skip to a different part of the venue.   its very loop intensive.
> 
> doing it out on the internet — takes many individual sql calls and there is a lot of latency in transmitting the data and waiting for it to come back.   so a stored procedure does it in under a second.     time savings = huge.
> 
> 
> in that case, part of the business logic is pulled out of omnis and moved closer to the database (stored proc) so its faster.
> 
> one final thing about store procedures… they are exactly on transaction for everything that is in it.  it either works or it doesn’t.    we don’t have to set up transaction boundaries.
> 
> 
> 
> the other place that we have put business logic is into python.   Why you might ask.
> 
> the python processes run on the same machine as postgres - so there is minimal latency.  its almost as good as a stored proc.        however, we have to worry about transaction boundaries and wrap multiple statements in.  begin(). commit() and do error checking with rollback().
> 
> 
> we will put more business into python so that its close to the database and we will take those functions out of omnis.   why again?
> 
> because python plays a strong part in our 3 tier architecture.  meaning.   user(omnis)—> python (logic) —> postgres (data storage)
> 
> the central tier means we can have other services talk to python in ordr to update the data.
> 
> 
> 
> where does that lead us, technology wise.
> 
> 
> ultimately, we have to remember that the internet is designed with breakage in mind.  connections die.   so if you write an app (in omnis) that assumes created a connection, uses it, and then throws it away in order to do something (like sell a ticket)… you start to win big
> 
> it means you no longer need a permanent database connection.   it means you can use an OW3 worker to send a query to the python server to update the database and end the connection.     you can do that many times simultaneously.
> 
> and when you do that, it gives you a robust, fault tolerant application that will fix itself up if an internet connection goes away (eg user closes laptop)  and then gets reestablished (use opens laptop)
> 
> 
> to answer things directly:
> 
> Omnis is really just a legacy desktop app that you keep and has nothing to do with the internet traffic, is this correct
> 
> not quite.  Omnis coordinates interface, error messages, allows data entry into fields, ensures data is complete, updates lists of data, provides reports .. gives local error messages, switched between tabs, … all the stuff it currently does.
> 
> however, the goal is to thin it out at the part where we would normally talk to the dam/table class to update the data … to call functions at the server (through a rest api or stored procedure — either/or)… and let the server handle the heavy work of ensuring the data is correct and putting into the database.
> 
> this minimizes data transmission where possible.
> 
> it allows other services (languages) to use the same rest api to get the same stuff done.
> 
> it allows users to write little micro services to tal fto their data without needing us.   example:  we have users that pull data and images out of their database to populate their main word press marketing web site (using the rest api)
> 
> 
> Further, are you moving the biz logic out of Omnis lbs into database to prevent code duplication?
> 
> 
> 
> yes. where its appropriate.     the goal is to do that 100%.     if all read and update logic is in the middle tier, it lets us change and optimize the business logic.  it also allows us to write automatic test cases to ensure data validity.
> 
> and given that more people writing code on a project tend to make it less successful, automated testing is one of the best ways of ensuring code works.    Code testing (shout out to Alex here for omnis tapi).. needs testing protocols/harnesses.      Server based coding with not interfaces, just business logic, tends to help a lot with automated testing processes.
> 
> 
> thats lets u get more done with less.
> 
> 
> hope that make sense.   man, this us a euromnis beer conversation.
> 
> 
> Doug Easterbrook
> Arts Management Systems Ltd.
> mailto:doug at artsman.com
> http://www.artsman.com
> Phone (403) 650-1978
> 
> On August 10, 2021, at 1:42 PM, Grzegorz (Greg) Pasternak <gpasternak at cogeco.ca> wrote:
> 
> Doug;
> 
> If I understand correctly, in your implementation the biz logic resides to some degree in the database in stored procs, the Omnis is really just a legacy desktop app that you keep and has nothing to do with the internet traffic, is this correct?
> 
> Further, are you moving the biz logic out of Omnis lbs into database to prevent code duplication?
> 
> Greg
> 
> 
> On Aug 10, 2021, at 4:29 PM, Doug Easterbrook <doug at artsman.com> wrote:
> 
> hi Greg.
> 
> for most apps, the ‘glue’ is the database/storage technology.      Everything we do derives from postgres.  even high volume fast access reddis files we use for caching - invariably start with postgres.       Postgres is the core.
> 
> around that … we use technologies that make success.
> 
> eg,
> 
> we use pgsql stored procedures when we weant some data manipulation to be really fast and close to the database
> we use linux cause postgres is faster an more scaleable
> we use CEPH on multiple machines to allow fault tolerant, cross machine, redundant storage of our data in postgres
> we use ProxMox to manage the linux machines that manage our data
> we use python because its really good at handling a lot of web requests simultaneously that allow people to get to the data
> we are going to use reddis cache to handle sepmaphores to allow access to the database under high volume loads
> we use omnis to handle back office data entry and reporting against the database.
> we build rest api’s to let users and programmers get access to the database using 3 tier architecture
> 
> the glue is your data base.   it is the constant that needs to be guaranteed to be there
> 
> 
> omnis is about 1/2 of our code base.  and its great at what it does on multiple platforms.  couldn’t do without it.      but the glue is the database.
> 
> 
> Doug Easterbrook
> Arts Management Systems Ltd.
> mailto:doug at artsman.com
> http://www.artsman.com
> Phone (403) 650-1978
> 
> On August 10, 2021, at 12:13 PM, Grzegorz (Greg) Pasternak <gpasternak at cogeco.ca> wrote:
> 
> Thank you for your comments.
> 
> Funny you have mentioned Go, I worked with the programmer on the project that involved Go, it was supposed to be "the technology" but he changed his focus after completing this project and moved to different language.  Btw, I am agnostic about the actual tool set needed for web part, as this would be delegated to an expert (or aspiring expert).  All I am trying to find out is if Omnis is still considered to be somewhat relevant as the "glue" for different technologies used.
> 
> 
> 
> On Aug 10, 2021, at 3:01 PM, ADJob <mats at adjob.se> wrote:
> 
> Hi,
> 
> 1. Is Desktop Apps a thing of the past?
> 
> In my opinion - YES!
> 
> 2. Is it making sense to keep existing Desktop Apps and develop complementary Web Apps?
> 
> I think the migration from Desktop to Web will take some years, so you may keep the existing Desktop. But focus on the Web App.
> 
> 3. Is it perhaps better to develop a Web App replacing Desktop App completely using non-Omnis technology?
> 
> I think that you will get the job done faster with Omnis Web. Maybe the magnitude of 5x. Non-Omnis technology consists of dozens of technologies you have to put together yourself.
> The bottom line is that you have to choose between time and money. Omnis will cost you money and Open Source will cost you plenty of time.
> 
> 4. Is there a place for Omnis to be a relevant part of Web App design?
> 
> About 50% of all developers are between 20-30 years according to StackOverflow. I asked the list if there are any youngsters on the list.
> The answer was practically zero. So I guess that Omnis will lack new fresh blood, considering that most of the options are open source and free. So I have my doubts that Omnis Web is the right path.
> 
> 5. Is there any commercially successful implementation of the Web App using Omnis technology?  If so, which part is it?  (Javascript remote forms?  REST? Ultra thin client?)
> 
> I asked this question on the list a while ago and I got a dozen of answers. Not encouraging. I am investigating Go (Golang) that has about 2 millions developers today. https://go4webdev.org
> But this path I should never consider if Omnis was more affordable.
> 
> /Mats
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 


More information about the omnisdev-en mailing list