Table and Query Classes good or unnecessary?
Doug, I could be wrong but don’t you use Omnis as a middle tier for your
app? if so, Im curious to hear your take on the comments Reg mentioned.
As others have mentioned, we are also keeping a close look at what Omnis
does in upcoming releases.
We are currently exploring the use of Django and REST framework as a middle
tier for our Omnis client applications.
On Thu, Mar 15, 2018 at 5:39 AM, Marten Verhoeven <email@example.com>
> Hi Reg,
> 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
> 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
> 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
> Both areas need focus and vision for me to have Omnis remain a long-term
> solution to build our software on.
> Marten Verhoeven
> —–Oorspronkelijk bericht—–
> 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
> 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.
> > Cheers,
> > Bas
> > _____________________________________________________________
> > 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
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:firstname.lastname@example.org