Table and Query Classes good or unnecessary?
The licensing can be a show-stopper, but doesn’t have to be. It depends on your application/business case. If you are building a (partially) free-to-use application (for example as an iOS app, which has a free version with in-app purchase to add functionality) it will probably a no-go with regards to licenses (you at least need to talk to Omnis about it). For us, we have a fixed amount of users. Adding a middle tier would require a bit more licenses, but not 2x. So the licensing cost is no issue at all for our situation.
I agree with your first remark: single threaded is easier to develop for, and that is fine for Omnis in my opinion. I don’t need the multi-threading power of clojure for my business application. It is a no-go however to have to handle all client requests in a single-threaded environment. You have to be able to respond to separate request at the same time, otherwise you are lost even with 5 users of your server. So in my opinion, multi-threading or multi process is required, even for small uses (and handling one request can be done in a single-threaded manor).
And about python… Oh boy…:-)
I am a novice, so I will probably be shot, but I will give it a try;-)
I don’t like that the indentation is part of your application flow. You can get different flow of your code even if it looks visually the same (by mixing tabs and spaces in the wrong way). That however can be solved in practice by using the right tools, and that is not why python currently is not my favourite language. Heck, I even really _love_ lisp and that notation is really awful. But somehow the dynamics and flexibility of that language make me love it.
I have only used Python a little bit. And it _is_ on my list for a middle tier to investigate further. I don’t have the love for it, _yet_. For a small part this might be caused by not having a closing part of a code block (so no “end if” or something like that). But the biggest part, I think, was my inability to comprehend the standard modules. For example, I struggled a lot with calling command-line tools. Should I use os.spawnl, or os.popen, or one of the many other? I know I am a novice with python, but that made me search a lot and did not seem very nice. However, I believe a lot of the modules are cleaned up in Python 3, so it might be a lot different now. I just don’t know as I haven’t converted my (small) code-base.
Clojure is not transpiled! Clojure is compiled to run on the jave runtime. Clojurescript is something different. Heck, clojure is created for multi-threading, and clojurescript is intended to run on a single threaded runtime. So, if we would use clojure, I would have to write the client side in a different language (I don’t think building a java-ui with clojure (or basically building any java ui) a good idea).
I mentioned protocol buffers. I don’t know ZeroMQ, but as far as I can see it is something different. Protocol buffers is a tool from google (developers.google.com/protocol-buffers/). Basically you define the interaction of data between your applications in a configuration file. Based on this file code is generated to handle transferring the data. With one definition you can create modules in different languages. So, on the server you create data, the protocol buffer transforms it to binary data (or text when required for humans to read), you transfer the data and read it back in the other application. The data transferred is small (as it is in binary format, so not like JSON or XML), it can be converted very fast to usable data in your application and it is type-safe. I haven’t investigated it enough to know if you can also generically define the data, which you need when you want to be able to specify the columns of a select dynamically. You could do the same thing quite ea
sily when server and client are both Omnis (you could transfer the binary data), but the advantage of a protocol buffer is that you can transfer data between different languages as well. It also takes version of the data definition into account (so a client with an older version of the code can still talk to the server with a newer version).
With kind regards,
Van: omnisdev-en [mailto:email@example.com] Namens Clifford Ilkay
Verzonden: donderdag 15 maart 2018 23:15
Aan: OmnisDev List – English <firstname.lastname@example.org>
Onderwerp: Re: Table and Query Classes good or unnecessary?
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.
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
> 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>
> – 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?
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