Canvas Nasal/JavaScript Subset: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Created page with "{{Stub}} {{WIP}} {{Nasal Navigation}} == Background == Given the recent mongoose/httpd work, we've been seeing some overlapping functionality that's already available in Nas...")
 
Line 23: Line 23:
We also need to keep in mind that props.nas may be updated using cppbind sooner or later to reduce Nasal space overhead.
We also need to keep in mind that props.nas may be updated using cppbind sooner or later to reduce Nasal space overhead.


== APIs ==
* setprop/getprop
* setlistener
* settimer
(it might make sense to directly encapsulate those APIs and use helper objects, as discussed on the forum)


== Design ==
== Design ==

Revision as of 14:50, 20 March 2014

This article is a stub. You can help the wiki by expanding it.
WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.


Background

Given the recent mongoose/httpd work, we've been seeing some overlapping functionality that's already available in Nasal space, for which Torsten specifically implemented JavaScript wrappers, i.e. to expose the Property Tree and its listeners to JavaScript.

One idea we discussed is to "compile" Nasal into Javascript and send it to the browser (together with the canvas as SVG), but we don't know yet if this is possible with a reasonable effort. Also we should ensure that the JavaScript API and Nasal API are identical, such the code can be easily converted/ported. So we need to define a safe subset of Nasal and JavaScript and come up with corresponding classes to wrap identical stuff. And there are a quite a few useful JS features that Nasal will never support, so we need to use factories for those to hide differences between both languages (sounds like something that Philosopher might enjoy), or someone will end up complaining that jQuery breaks Nasal...

Goals

Come up with a common Nasal/JavaScript subset that works in both environments (browser/fgfs), and use factories for hiding platform differences, for example:

  • property tree
  • listeners
  • props.nas

For reference, look at TorstenD's WebGUI work which is heavily overlapping with props.nas stuff. However, we need to keep in mind that there are certain APIs that will never be supported out of the FG context, while others may simply be "delegated" via FlightGear (webSockets, e.g. timers/listeners).

So we kinda need to formalize both environments and come up with a minimal API subset that supports versioning.

We also need to keep in mind that props.nas may be updated using cppbind sooner or later to reduce Nasal space overhead.

APIs

  • setprop/getprop
  • setlistener
  • settimer

(it might make sense to directly encapsulate those APIs and use helper objects, as discussed on the forum)

Design