Table and Query Classes good or unnecessary?
I have to admit C# is slowly bubbling higher on my list as well
especially with Mono making it very much a cross platform contender and
C# as a language being one that I am very familiar with (I did some
years of C# programming along side of Omnis programming when my previous
employer was moving from Omnis to C#).
I just haven’t found good frameworks yet that allow you to hit the
ground running building purely a BI middle tier. Too many people who tie
into Microsofts server stack which we don’t want to touch but
admittedly, I haven’t searched hard enough. Any suggestions for products
to look at here?
Agree with most of your points on Omnis as a middle-tier. Admittedly
though, a lot of that is from days gone by when we used the original
thin client in Studio 3 when this was all new, and looking at feedback
from people who’ve done a lot in Studio 4. With so much attention on
this in Studio 8 for the java script client I imagine things are
improving. Whether they have improved enough is hard to say until we
start getting more feedback from Omnis developers who have gone down
I’d like to add a 5th problem that is high on our list of important
things and that is the security aspect. While most people make the
mistake of trusting security to their chosen platform and ignore that
security is just as much a factor of how you write your own code, Omnis
Studio’s closed architecture and relatively low market penetration means
there aren’t many eyes on finding security holes in the system (and I
fully realize that’s a chicken and egg statement, they are not going to
get that market penetration if people don’t use it, and if people won’t
use it because they haven’t got that market penetration… some of us
will have to take that leap of faith).
With hosting a solution that is publicly accessible and has a high
visibility for potential hackers choosing a tool that has wide use so
that best practices in security for that platform are well known and
where holes are quickly found and plugged is an important factor for us.
We don’t trust in security through obscurity..
Mind you, I have to underline here with double or triple underlines,
while this is a concern for us this does not mean Omnis Studio is not a
secure server solution. But Omnis Studio is fighting an uphill battle
here to convince people they have done the right things so that any
security issue in my application are indeed my fault. In my eyes they
did recently win a battle in this regard. I think it was Birgit that
mentioned it in a conversation I was a part of, but I might be mixing
things up so don’t take this as anything official, but there is a big
scale that did some serious testing on this and gave Studio a clean bill
Still, the information on how to build a secure solution in Omnis Studio
is not readily available so it is something that I hope and trust Omnis
Studio will put more focus on. Contrary to popular belief, it is not
enough to put Apache in front and turn on SSL. That’s where security
starts. It is far from where it ends (and unfortunately, that popular
belief has resulted in over 90% of sites on the web not having security
up to par, hardly a problem only Omnis suffers from).
On 15/3/18 8:39 pm, Marten Verhoeven 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.
> 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.
> 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 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