An interesting experiment with JSON, Postgres and Omnis

[Sten-Erik Björling]

Last year I did a presentation at the German Regional Omnis event covering planned approaches using Omnis in development of innovative and complex solutions.

The main points in that presentation where:

- When developing solutions that are paradigm-shifting you very seldom know at the start what the system will look like…
- If the finalised system is planned to be truly expandable and able to support future added demands for added functionality then the system needs to be designed to support those demands with tested and stable APIs and modular architectures.
- If the system is planned to be ”right” for growth and future expansion and interoperability instead of just ”right now” forcing a speedy implementation then extensive testing and feedback from large user groups and contexts are needed. Which will generate a large number of revisions, tests and additional feedback - which will demand a very efficient development of new revisions for testing.

Thus - my recommendation when trying to develop ”paradigm-shifting” systems is to develop the solutions in two different stages - one optimised for fast development of pilots, used to support fast development of the specifications of the finalised system and when that stage is finished the ”hunt for the optimal development environment” will start.

The disadvantage to be the hostage of all these nice frameworks out there with all their nifty and efficient GUI tools and interoperability abilities is that when the development of the solutions start with a thorough piloting and testing phase, when that phase is finished the whole marketplace will be completely different compared with when you started. And then you are sitting there with a system based on most code based on old versions of the chosen frameworks and even worse - you find out that the currently selected toolset is totally inadequate.

The advantage with Omnis as I see it as a prototyping tool is that one can create comprehensive solutions for testing and initial deployments fairly quickly - since the need to be fluent in a number of different development environments are minimised - not needing to be too deep into DB programming, python, JavaScript etc. and still getting a testable system out there to help you evaluate traps, needed functionalities and points of interoperability.

Omnis as a toolset should be upgraded as I see it in the following areas to also support deployment of very large systems:

- The GUI components in the JS systems must be updated to be more attractive - and it would be a good idea to create in the Omnis dev. GUI some tools to simplify the integration of external JS functions and GUI elements.
- What happened to the dedicated iPhone environment? I can understand that keeping up with the updates from Apple takes resources - but one have to consider that the iOS users has a disproportionate impact on the acceptance of solutions based in quality  of the user interface.
- Proper implementation of the touch interface is missing.
- Omnis Application Server can be faster - even though it is quite fast today with proper programming - there are some bottlenecks in the system today that should be worked over. Also when it comes to some memory management there are some issues.
- The pricing structures for both the development environment (currently blocking new developers coming into the platform) and server licenses should be subject to evaluation.

Take care, all the best…

Stene

_______

> 16 jan. 2017 kl. 08:44 skrev Mike Matthews <omnis at lineal.co.uk>:
> 
> An age old problem then.  
> 
> Currently you need just a few bits and pieces available in JS, just as we do.  But what is the line?  And how long long will that line last?
> 
> I remember going from 07 single library to O$, multi library and then SQL from DF1, all at the same time!  No point in not, and we took 3 goes at doing it, throwing away work that was started.
> 
> I suspect that in the long run, 5 years maybe, we will want to have just one development platform, and all of the software running in that platform.  But we will take small steps this time, just like yourselves.
> 
> One thing for sure, although Omnis has evolved over 30 years, I have stayed with it.  I can say I haven't changed from Omnis, but Omnis sure has, and has carried my code with it.  Mostly.  But if I were to change over to a new set of tools, how transportable will my code be over the next 15 years?  If you go back 15 years, which of those languages and tool sets are still supported?  How convertible is the work done in those environments to today current best set?  And how good will the change be in another 5, 10 and 15 years be?  Seamless? Not that the new tools won't be bad, it is just the work involved in the migration.  A younger man's job maybe.
> 
> My last point about swapping tools regularly relates to our product SQLWorks.  It is a vertical solution that we sell.  It does a lot, but it is a single tool.  If your business is to write new solutions for different clients, then you can change tools often I would imagine, and transporting bits of precious code with you, updating where necessary.  You will come across different kinds of problems that require different solutions.
> 
> But it is never an easy choice for sure.
> 
> Mike

Sten-Erik Björling
Enviro Data
Kyrkogatan 5A 2 tr
SE-972 32  Luleå
Sweden

E-Mail: s-e.bjorling at enviro.se
Mobile: +46-70-655 11 72
Skype: stenerikbjorling
iChat: stene at mac.com
FaceTime: stene at mac.com
Hotmail / Messenger: stenerikbjorling at hotmail.com
GMail: stenerikbjorling at gmail.com

______

This email and any files transmitted with it are confidential, may be legally privileged and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please note that any use, distribution, or reproduction of the contents of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by return email and destroy all copies of the original message including any attachments thereto. Thank you.

Please note that we take reasonable precautions to prevent the transmission of viruses; however, we cannot guarantee that this email or its attachments are free from viruses. We only send and receive emails on the basis that we are not be liable for any loss or damage resulting from the opening of this message and/or attachments.