oBrowser -- Is there a demand for this?

Tue Mar 14 20:19:43 EDT 2017

Hi Andrew,

This is where oBrowser and/or you desktop browser can play a joint role in helping you get where you want.

> For example, if I want to start moving some core thick client windows over
> to the JS client, I assume I would be able to open it with oBrowser, but
> you are then stuck paying licensing for the Omnis thick client runtime PLUS
> the JSclient runtime for that same user.
> 
> At that point, you are essentially being pushing away from the JSclient and
> doing things like Clifford mentions. Our application is very large, without
> doing incremental transitions its hard to justify using the JSclient and
> paying "twice" per user.

First off, you talked about licences and costs. The simple answer to your question is, you ** may ** extra licences. You can setup omnis runtimes in a network such that it works out for you during this transitionary phase.

Solution #1...
There are “fat” (desktop) and “thin” (JS/remote forms) client runtime licences. 

If you look at the serial numbers they’ll be for a web server licence. So, technically your fat client is actually a single (or multi user) web server on its own. (or you can order web runtime codes only, they still work as fat client runtimes, unless I am grossly mistaken.)

Client ——\							/—— Client	
		  ==== <> LSP <> Apache/IIS <> ====
Client ——/							\—— Client		

Using this bit of knowledge you can now start to plan on designing either 
a. Fat/Thin hybrid solution, or,
b. Fat/RESTful API hybrid solution, or,
c. SaaS type solution.

I think we have all heard of multiple demos and examples on how the SQL worker objects work, its similar to what I’ve shown up here. Similarly you can design your reporting engine to offload the big reports to another “free” client on your network and get back to you with a response, etc…. 

This allows you to design a hybrid solution that works like a mesh-network solution. This will work with fat clients  (oBrowser) and any other technology you’d like to integrate, like RESTful API or JS client or non-omnis 3rd party apps that consume services published from your app/technology. 

Solution #2...
You can talk to your Omnis distributor and come up with a solution on runtimes. They can provide you with, long term demo codes if you need to help you move towards a suitable outcome. Also the time is right to flip the switch they can also work with you to convert those fat client into a multi user web code too. (I am confident.) 

Finally,...
With the breadth of tools and technologies Omnis provides us, we are now only bound by our conceptual limitations. =) 

And also, here comes the plug about what I do (me)... :o) 

I offer consulting and development services to help you get you where you want by using Omnis and other technologies, not necessarily in Omnis. I tailor solutions that depend on how the target product needs to be consumed and maintained in the future.

Drop me a line if you like. :-)

Regards,

Vik Shah
Director
Keys2Solutions
AU: +61 411 493 495
SE: +46 21-495 01 05
US: +1 (415) 413 4172

> On 14 Mar 2017, at 23:59, Andrew Stolarz <stolarz at gmail.com> wrote:
> 
> One of the biggest problems with the omnis JsClient is that you cant even
> transition your thick client application to use it without duplicating
> licensing fees.
> 
> 
> For example, if I want to start moving some core thick client windows over
> to the JS client, I assume I would be able to open it with oBrowser, but
> you are then stuck paying licensing for the Omnis thick client runtime PLUS
> the JSclient runtime for that same user.
> 
> 
> At that point, you are essentially being pushing away from the JSclient and
> doing things like Clifford mentions. Our application is very large, without
> doing incremental transitions its hard to justify using the JSclient and
> paying "twice" per user.
> 
> 
> 
> Andrew
> 
> 
> On 13 March 2017 at 20:08, CLIFFORD ILKAY <clifford_ilkay at dinamis.com>
> wrote:
> 
>> Hi Bas,
>> 
>> One can build native mobile apps using purely JavaScript so I don't see
>> how speeding up the Omnis core is going to make any difference for web
>> applications. As for desktop applications, it seems pointless to me to have
>> a parallel development effort just for desktop applications when the web is
>> the new runtime.
>> 
>> The next big breakthrough in web applications is having languages target
>> WebAssembly <http://webassembly.org/>, which just started shipping with
>> Firefox. It is in the Chrome Canary channel already. Edge and Safari aren't
>> far off. With the current revenue model of Omnis, it's unlikely that Omnis
>> will ever target Web Assembly, which is not to say that with a different
>> revenue model that things could not change.
>> 
>> As for the usefulness of oBrowser, if it's anything like the Chromium
>> Embedded Framework XCOMP we've built for Studio 4.3.2.1 that enables us to
>> embed CEF in an Omnis window, it's a great way to migrate out of Omnis. If
>> oBrowser allows for bi-directional interaction with Javascript running in
>> the control and Omnis, it would enable a developer to incrementally migrate
>> fat-client windows to pure web windows that eventually have no need for an
>> Omnis container once the last fat-client window has been migrated. If
>> you've done this right, with that one JS codebase, you'll be able to build
>> native iOS and Android apps and distribute it on desktop operating systems
>> using Electron.
>> 
>> The days of JS being a toy language for a few animations here and there
>> are long over. You can build something that is every bit as rich or richer
>> than Omnis using modern Javascript.
>> 
>> --
>> Regards,
>> 
>> Clifford Ilkay
>> 
>> + 1 647-778-8696
>> 
>> 
>> 
>> On 13/03/17 05:34 AM, Bastiaan Olij wrote:
>> 
>>> Hey Kelly,
>>> 
>>> Very cool mate!
>>> 
>>> That said, I do similar things in Omnis :P
>>> 
>>> I do think HTML with a bit of Javascript is a more powerful tool for
>>> displaying complex data then Omnis is. Well at this point in time.
>>> 
>>> I don't know enough about the optimizations the guys in the UK have been
>>> doing lately. Last time I talked about this with Bob (W) at EurOmnis he
>>> let slip that part of the focus of the 6.2/8.x rewrite was to optimize
>>> some of the internal core of Omnis. If that means faster
>>> creation/destruction of subwindows and better performance in redrawing
>>> the contents on the screen especially when there are many subwindows on
>>> the screen, then that balance may tip in Omnis' favor again.
>>> 
>>> I like the look of your app btw!
>>> 
>>> Cheers,
>>> 
>>> Bas
>>> 
>>> On 13/03/2017 7:08 PM, Kelly Burgess wrote:
>>> 
>>>> I’d like to ask the list if oBrowser is in use
>>>>> 
>>>> Working on it.  Don't read too much into any of this, it's quite full of
>>>> placeholders at the moment . . .
>>>> 
>>>> This htmlcontrol lets me display phone numbers, emails and physical
>>>> addresses in a single scrolling space, with expand/collapse buttons so I
>>>> can show just the first one or reveal all the phone numbers, and everything
>>>> else just pushes down and makes room.  Much more flexible than a complex
>>>> grid object, since each row doesn't need to be the same height.  The mailto
>>>> link behavior comes along for free with the proper markup, and those
>>>> copy/edit/delete buttons only appear when you hover over their context
>>>> space.  An add button appears when you hover over the categories.
>>>> 
>>>>      http://www.kellyb.com/htmlControls/elasticGrids.png
>>>> 
>>>> This htmlcontrol lets me produce a 3-D list, where I can expand a line
>>>> and allow drilling down into many different related details.  Here I've
>>>> expanded lines 3 and 5.
>>>> 
>>>>      http://www.kellyb.com/htmlControls/3dList.png
>>>> 
>>>> I think this is a great tool. One of the hover buttons for addresses
>>>> will open another window with a google map of the address.  Not needing to
>>>> leave Omnis to show web pages is a real step forward.
>>>> 
>>>> Kelly
>>>> 
>>>> _____________________________________________________________
>>>> Manage your list subscriptions at http://lists.omnis-dev.com
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
>> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com