Table and Query Classes good or unnecessary?

On Thu, Mar 15, 2018 at 5:39 AM, Marten Verhoeven <m.verhoeven@van-beek.nl>
wrote:

> 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.
>

This would not be a problem if it were not for the following points,
especially #3. Single-threaded, single-process languages and frameworks are
easier for developers to build, debug, and maintain so that in and of
itself is not necessarily a show-stopper. Let’s pretend for a moment that
#2 through #4 below aren’t true or overstated. How does licensing work for
a cluster of Studio app servers? If it costs $X for one instance and $NX
for N instances, that’s a show-stopper.

> 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.
>

Please don’t tell me that you’re one of those heathens who objects to the
language enforcing whitespace. 🙂 Omnis does that, too. Python 3.6 is
competitive with any language and far more approachable. It’s a small and
simple enough language that even people with no prior programming
experience, like high school students, can pick it up without much
ceremony. You have a choice between dynamic typing, like Python
historically has had, or static typing. You have native coroutines which
enable to write asynchronous code that is easy to understand. < docs.python.org/3/library/asyncio-task.html>

As for not being an option for client-side development, that’s simply not
true. If anything, there are too many options so figuring out the one to
use is often the biggest challenge. I’ve used Python to build native
Windows and Linux applications using PyQT and PyGTK and there are even more
options today for native development. For web clients, it’s the same
approach you’d have to take with any language that is not JavaScript,
transpilation. One example of that approach is Transcrypt < www.transcrypt.org/>. There isn’t a solution for building native
mobile apps using Python that I know of, which doesn’t mean that one
doesn’t exist.

> – 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.
>

Again, transpilation. <github.com/clojure/clojurescript>

> 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.
>

Are you talking about message queues like ZeroMQ and such?

Notable by its absence is the entire JavaScript ecosystem. Using pure ES6,
you can write server-side and client-side code on any platform that
matters. If you prefer to use some other language, you can probably find a
transpiler that outputs JavaScript. < github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
>

Regards,

Clifford Ilkay

+1 647-778-8696
_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com