comp.lang.ada
 help / color / mirror / Atom feed
From: David Botton <david@botton.com>
Subject: Re: Gnoga and Wasabee
Date: Sun, 7 Dec 2014 20:25:34 -0800 (PST)
Date: 2014-12-07T20:25:34-08:00	[thread overview]
Message-ID: <08b6285b-0089-421f-b6ee-eca3c5eca40f@googlegroups.com> (raw)
In-Reply-To: <eb84f3d2-32df-4d1a-9193-f704024d6315@googlegroups.com>

<<Gnoga claims to be a cross-platform mission-critical framework for GUI applications, it achieves this goal by using browser. However, this, inevitably, will use Javascript to communicate with the server.>>

Javascript is not used in the logic only in the insertion and removal of elements in to the DOM or to signal the Ada code an event has occurred.


<< My doubt is, technically, is Javascript a good choice for mission-critical applications?>>

It is not and one reason to use Gnoga in its place.

<<I never liked Javascript, when I heard about Node.js, I couldn't understand it, why someone want Javascript on the server side, the explanation I came up with is, people are different, some of them like Coke, others like Pepsi.>>

Or more likely the developers do not know another language and didn't expect someone would do something foolish like use Node.js in a banking environment like paypal...

<< The moment I heard about Gnoga, I was excited, I thought it is something like Qt framework, but clearly I was wrong.>>

No your understanding of how Gnoga uses the browser as a rendering engine vs. using the browser to execute application code is wrong. So keep up the excitement, perhaps go through the tutorials, etc. and get ready for when I deliver in the next week or two some of the native client setups.

Just like Qt uses the underlying X11 server to render the GUI, Gnoga uses the browser. Very little difference between the two.
 
<<I am thinking, is it a good idea to combine Gnoga and Wasabee [Wasabee is a web browser focus on correctness]?>>

I think that for complete client side applications where Wasabee can run that using Gnoga with Wasabee is an excellent idea. Not in the git yet, but I already have a more tightly coupled setups with WebKit and Gnoga and post 1.0 I will have versions that do not even use WebSockets for the underlying communication layer but direct calls in to WebKit for desktop and mobile apps.

> Pros:
> * We can throw Javascript away, use Ada as its embed language.

You already can with Gnoga as is. There is no Javascript programming occurring. However, Gnoga can make use of JavaScript components as plugins and one of its great advantages. However the core Gnoga framework does not make use of anything but HTML elements.

> * No need to care about the difference between browsers, since we only use Wasabee.

That is already a non-issue from the perspective o Gnoga programmer. The only cross incompatibility that has been found was in popup-windows and that tutorial will be replaced in the near future as popup windows should not be used in general outside of launching another website.

When Wasabee is mature enough I certainly hope that it would be used in the capacity you are stating with Gnoga. There are certainly advantages to using it over WebKit or general browser access.

> * Focus on the focus that the project claims to focus, like security, safety, etc..

The current claim is to provide a GUI that works over a large spectrum of devices beyond just the desktop and it does that well. By not using JavaScript (contrary to your misunderstanding of Gnoga) and using Ada outside the browser for the entire application logic, including control of the GUI, it is possible to write more secure and safe applications.

It is, even at this pre-1.0 stage, on par with any other GUI toolkit as far as allowing the use of Ada for mission critical and secure application development.

While Gnoga, especially in the current demos, is being used more for remote web-apps (since at this stage we are trying to demo it over the web to garner interest :), others are already using it for local only GUIs, in the same way Qt or Gtk are used. I have Mac and now Linux native desktop clients working now as mentioned.

> * We can even discard HTML, invent a new markup language, like Mozilla UML? [I am not sure this is a good idea, just put it here]

I assume you meant XUL. Which interestingly enough at some point I will likely write a Gnoga Plugin to use it if I can find the time. I'd also like to set up native clients using XULRunner which is has advantages over webkit but so far seems far more difficult to incorporate in an app.

> * Use proof-based programming, by proof-based programming, I mean, you can rely more on Ada Contract than testing.

That can be done now using Gnoga.

> Cons:
> * Wasabee itself is in early stage, so, have a lot of work to do, but at least we are on the right direction.

I agree and look forward to using it as an excellent head for Gnoga apps when ready.

> * Not cross-platform until you can run Wasabee on every major OS.

When writing mission critical apps you often choose the hardware to match the software so this is less of an issue than you may realize.

> * Need Wasabee to run. [I don't think this is a disadvantage, you can distribute Wasabee with your application]

Of course.

David Botton

  reply	other threads:[~2014-12-08  4:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-08  3:38 Gnoga and Wasabee moixa
2014-12-08  4:25 ` David Botton [this message]
2014-12-08  9:18   ` Simon Wright
2014-12-08 12:25     ` David Botton
2014-12-09  5:02 ` johannes falcone
2014-12-09  6:26   ` J-P. Rosen
2014-12-09  8:12 ` moixa
2014-12-09  8:24   ` Dmitry A. Kazakov
2014-12-09 13:01   ` David Botton
2014-12-09  8:39 ` moixa
2014-12-09  9:12   ` Checking (was: Gnoga and Wasabee) Simon Wright
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox