Table and Query Classes good or unnecessary?
I think there are three problems currently with Omnis as a middle tier (maybe four):
1. Omnis doesn’t handle multi-threading / multi process very well. You have to install multiple instances to get multi process and add an intermediate layer in between to distribute the calls.
2. Remote tasks are currently supposed to handle calls, but they are instantiated on every request which makes it hard to use prepared or cached data/objects. So, if you instantiate a table class, you cannot keep the instance alive for a next request, which means you need to instantiate it every time, or only use the main thread (which basically means you don’t use remote tasks as intended). This means a lot of overhead which kills performance.
3. It is too unstable for a server-process. If a call causes a crash, the complete service is taken down. A crash of a call should only take down the execution of the current call, not the complete service.
4. When adding a middle tier you add an extra layer on top of the (very fast) database access. So this extra layer should be very fast, and Omnis is not very fast. Especially not in manipulating big lists. So core-improvements to get performance gains can be required (depending on what you do). Just making sure to get the data from the middle tier to the client quickly can also be achieved by building an external component just for that, so that might be enough.
I have not investigated contenders heavily yet, but I would first look at:
– C#: very capable language and I could also build some client side stuff in the same language (windows, iOS and android). It is a big ecosystem backed by and important for Microsoft, so it won’t go away.
– Swift: Very capable and fast language and I could build some client side stuff in the same language (iOS only. Not being able to run on windows is a drawback). It will be remain a big ecosystem going into the future, as apple and IBM put a lot of weight behind it. Swift is the future for Apple, so that is pretty safe
– Python Lots of libraries on the server-side, but I am not a fan of the language and the tools I currently know and it is not an option for client-side development.
– Clojure – This is a very small contender. The only reason I am adding this is that I know common lisp pretty well and know how powerful and flexible the language is, but there probably are a lot of downsides to using it because it is a small ecosystem, not an option for client side development.
I would also investigate whether I could use protocol-buffers for communication between server and client in order to get fast transfer between them. I’m not sure if it is dynamic enough though. There still is a lot to investigate for me.
I do hope Omnis will be a viable option as well, because it is really flexible and very, very fast to develop in. And I can reuse a lot of code, so that is a big advantage as well.
But client side Omnis requires a major update as well, in order to build more modern, dynamic user interfaces instead of static windows 2000 style interfaces.
Both areas need focus and vision for me to have Omnis remain a long-term solution to build our software on.
Van: omnisdev-en [mailto:firstname.lastname@example.org] Namens Reg Paling
Verzonden: dinsdag 13 maart 2018 0:30
Aan: email@example.com >> OmnisDev List – English <firstname.lastname@example.org>
Onderwerp: Re: Table and Query Classes good or unnecessary?
Hi Bas & Marten,
What enhancements do do want to see in Omnis, to better support the middle tier? What alternatives are you looking at, and what are their strengths etc?
On 13/3/18 9:39 am, Bastiaan Olij wrote:
> Hey Marten,
> On 12/3/18 8:55 pm, Marten Verhoeven wrote:
>> If they just prioritize the JS client I will have to make different choices. If they focus on the fat cl
>> ient to build your UI and on a better backend platform I will keep it all in Omnis.
> Exactly the choice that is in my head too. The JS Client is nice but
> its not a technology that currently interests me a lot. With where
> Apple seems to be headed I much rather see a continuation of
> enhancements in the fat client and as I’ve said many times before,
> hopefully some day an iOS runtime which should be within our grasps
> now that Studio 8 has seen the Mac OS X client rewritten.I believe it
> is even inevitable as I think we’ll soon see iMacs or similar devices
> running iOS. The JS Client I presume will remain a large part of
> Omnis’ future seeing how successful it has been bringing in new
> opportunities but I hope the company will see chances in the fat
> client and improving the middle tier capabilities also helps the JS
> client so that one is a given. The question for us is, will it be in
> time? Right now the most likely future for us seems to be using Omnis
> as a front end but another tool for the middle tier. The choice is not
> made however 🙂
> That all said, I can only underline how enthusiastic I am for the
> change of direction Omnis has shown. It’s definitely a matter of
> giving them time for this to start showing fruits. It takes awhile
> before a new direction gains momentum but I think we’ll be seeing some
> exciting new things soon.
> Manage your list subscriptions at lists.omnis-dev.com Start a
> new message -> mailto:email@example.com
Manage your list subscriptions at lists.omnis-dev.com Start a new message -> mailto:firstname.lastname@example.org
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:email@example.com