Comments on: Let’s Talk About CEF

By: Marcin (WebSimConnect)

Marcin (WebSimConnect) — Wed, 18 Apr 2018 12:06:08 +0000

In reply to Tyler Young. So why don't you simply build stand alone app integrated with CEF that will do the job keeping core XP out of it ? At least until the moment you decide what to do with CEF.

By: Marcin (WebSimConnect)

Marcin (WebSimConnect) — Wed, 18 Apr 2018 10:14:46 +0000

Let me jump into the discussion. I am the author of WebSimConnect. A framework that integrates CEF with FSX/P3D and XP. The first XP release was completed 3 years ago (July 2015). That was still CEF version (Chromium 39) that required copying/linking files into XP application bundle. That is not needed any more. As I was aware from the beginning that only one CEF can exist in the same process space I knew that sooner or later that would create conflicts between add-on builders and the CEF integration shall be “centrally” owned/managed due to this technical constraint. Unfortunately this goes against free usage as XP add-ons will be limited to what LR is providing. In fact I am l loosing my business by introducing CEF integration at XP level by LR as some of my clients that wanted to release soon their aircrafts using my framework will simply migrate their work towards XP-CEF. Anyway, that’s life. Below are my thoughts on CEF integration.
1) HTML5 is a breakthrough in virtual aircraft development and I am not talking about putting youtube on virtual ipad in the aircraft or even developing EFB. Today building modern glass cockpits using it classical way (C++, lua, open gl or DX on Win) with just small teams and limited resources seams like mission impossible. Using HTML5 with tons of useful libraries makes the task much easier and faster. For example it allowed Sim Skunk Works to put very sophisticated instruments like Terrain Following Radar, Map display, etc. into their Tornado Panavia aircraft. It also allowed me to build Synthetic Vision for Carenado aircrafts.
2) The security aspect must be taken into account, however do not exaggerate the problem. There are already lot of application using CEF that you might not be aware of (e.g. Steam Client ). What matters is that you accept add-ons from trusted providers. (even if they are script based only) and it is same story as accepting binaries coming from internet. Still CEF integration must limit some usage that might be considered risky. You could limit access to localhost or provide whitelisted domains etc. Still accepting XP add-on is same act as accepting any software to reside on your computer which is always a risk.
3) The real gain of using CEF is rendering HTML5 page with sim data and allowing to interact both directions. There is no need for sophisticated integration. What I did and it covers almost all use cases is:
from add-on (C++ or using DataRefs to allow lua or other scripting integration)
– allowing to call Load HTML from string
– allowing to call JavaScript function
(I simply exposed 1 class with members LoadHTML and ExecuteJavaScript) that is easily accessibly through C++ plugin.
and from JavaScript
– allow to call native C++ function that plugin developer capture in his code.
– allow to set DataRefs (also custom dataref with c++ handler )
so I exposed in JavaScript 2 functions having just one string argument that can be set to anything (for example JSON data) as the add-on handler will parse it for its needs.

In my opinion there is no need for more. Such simple API design enables endless opportunities for virtual aircraft builder and there is no need to go into CEF API at all.

In addition to build custom webpage for XP rendering without the need to connect to any website you need lightweight and secure webserver to be installed on local PC. In my framework I also included the websocket server that allows to port the instrument to external browser e.g. on mobile device and provide the sim-browser communication using webscoket protocol.

By: Tyler Young

Tyler Young — Tue, 17 Apr 2018 18:31:47 +0000

In reply to Francisco Sedano. That works for accepting payments (well, assuming users are willing to use Paypal!), but not the problem of distributing keys. We'd need PayPal (or whatever other payment processor) to report to a server of our own to inform us of the successful transaction, and have that server distribute the actual authentication key. Again, that custom server requires a lot more battle-hardening than just using the existing web site checkout.

By: Francisco Sedano

Francisco Sedano — Tue, 17 Apr 2018 18:22:10 +0000

In reply to Tyler Young.

Fair enough. Also based on the next post, I understand the idea is to use the browser engine as a resource for other features, that changes the picture…

For payment, I was assuming PayPAL REST is good enough, but TBH I’ve never tried it myself:

https://developer.paypal.com/docs/api/overview/

By: Tyler Young

Tyler Young — Tue, 17 Apr 2018 12:52:00 +0000

In reply to francisco sedano. Of course, we could replace literally any use of a webview with REST calls. It's just an issue of where we spend development time. Integrating with our existing (i.e., web-based) sales infrastructure was much cheaper time-wise than:

Developing a sales server capable of accepting credit cards and able to spit out authentication keys
Making said server resilient against all the scary things that happen in the wild (network failures, DDoS, etc.)
Making said server's handling of credit cards PCI compliant, so that we won't get our pants sued off
Maintaining said server into perpetuity

Had our existing sales infrastructure had a REST API that we could drop in, it would have made life a lot easier, but in our research, we didn't find any vendors that had the combination of the right API and the right features for distributing a digital download key.

By: francisco sedano

francisco sedano — Tue, 17 Apr 2018 12:15:17 +0000

If I can add my opinion here, this looks like asking from trouble. Can I suggest a different approach?

Do you *really* need to bring a browser to do the in-app upgrade? Why not just use an app form, and just do the transaction using any REST interface using libCURL as you do today for the stats, etc?

Yes, adding the browser allows you to fully update the page appearance, but an in-app form should be good enough, and you can always update the contents via REST calls.

By: Let's Talk About CEF (Some More) | X-Plane Developer

Let's Talk About CEF (Some More) | X-Plane Developer — Mon, 16 Apr 2018 20:53:19 +0000

[…] CEF post generated a lot of controversy, and rather than replying directly to in the comments (and doing a […]

By: Tyler Young

Tyler Young — Mon, 16 Apr 2018 13:54:57 +0000

In reply to sparker. The new APIs are shipping in the latest beta. I'm going to get the docs updated today.

By: sparker

sparker — Mon, 16 Apr 2018 10:28:57 +0000

In reply to Ulrich.

As someone that is waiting for a updated SDK that includes support for Widgets in VR and XPLMSetWindowVrSize() and XPLMGetWindowVrSize() to match X-Plane 11.20b5 I am wondering when these issues will get attention?.

I am one of the developers that has built, tested sent in bug reports to make sure before X-Plane 11.20 goes final most of the VR bugs are gone so the team can focus on other things.

The one upcoming thing after VR is Vulkan which I hope will bring VR to my Ubuntu machine.

Thanks Bill

By: Gene Thomas

Gene Thomas — Sun, 15 Apr 2018 05:15:15 +0000

I use Nothing from google, I don’t even like it when someone emails me from a gmail address (I’m in the industry and know too much about them.) I’ve been using x-plane for 6-7 years, developing secenery for 5, please don’t force me to quit.