In the X-Plane 11.20b1, we’re shipping a web browser for the first time. We’re using the Chromium Embedded Framework (CEF)—essentially the same guts as Chrome, wrapped inside X-Plane.
For the time being, it’s being used in one place only*: to support in-app upgrades, so that if you have the demo, you can buy the full version of X-Plane without having to go to the web site. The web view is seamless—you can’t tell by looking at the app that it’s not just part of the native X-Plane user interface.
While its present use is quite limited, if all goes well, we’d like to expand its use elsewhere in the sim—in The Glorious Future™, we could potentially use it to load online charts and the like.
But, there’s a hitch!
There’s not a good way to load two copies of CEF at a time. And, since some plugins (like the ones used in the new Flight Factor A320 Ultimate) depend on a version of CEF provided by a (global) plugin, we have to disable X-Plane’s web browser functionality in the presence of that plugin. This isn’t a big deal right now—after all, if you’ve installed payware, you probably already own the sim anyway—but it will be a shame if, in The Glorious Future™, you have to choose between your payware and core X-Plane functionality.
The situation is even worse than you might expect: CEF absolutely doesn’t support multiple initialization calls in the lifetime of an app—you can’t initialize it, shut it down, then re-initialize it. That means it’s not even possible for plugin authors to be good citizens and “relinquish” CEF to X-Plane, such that you could at least use X-Plane’s browser whenever you’re not using an add-on that depends on it. It’s all or nothing! In fact, you’ll have to uninstall the CEF plugin before X-Plane can use a web view itself.
There are two possible fixes here:
- At some point in the future, we provide access to CEF via the plugin SDK. If we did, it would have to be to the C API only—no fancy C++ wrappers for you. Speaking as someone with the memory of writing for the C API fresh in his mind, let me say: this isn’t a whole lot of fun, and it’s rife with the potential for memory leaks. Moreover, this would break any existing addons that depend on CEF—they would be forced to migrate to the SDK version of the API.
- We could (theoretically) compile an X-Plane-specific version of CEF that would not conflict with the version plugins are using. This would require renaming all the Objective-C symbols on Mac, and renaming the DLL on Windows. I’ve not investigated this for feasibility, but it’s certainly theoretically possible. This would allow X-Plane’s version of CEF to coexist with (one) plugin-provided copy, albeit at double the CPU and memory cost.
Having us expose CEF via the SDK is not an unequivocal win. CEF is notoriously incompatible between versions—you can more or less guarantee that even minor updates will break compatibility of the API somewhere. That means X-Plane would be stuck at a fixed version of CEF for at least the lifetime of a major version to prevent breaking plugins. X-Plane 11.20 uses CEF release 3202; it would be at least the next major version before we updated CEF to a newer version. There are two major downsides to this:
- When X-Plane updates to that newer version, it would break plugins compiled against old versions of the SDK that depend on CEF. That’s a lot more aggressive than our normal deprecation policy, and it makes CEF plugins a potential maintenance headache for plugin devs.
- If your add-on really, really needs features from the latest and greatest CEF release, you’re out of luck—wait a couple years (!!) and maybe we’ll update.
So, here’s what I’d like to hear from plugin devs:
- Are you currently, or are you planning to use CEF in the future?
- Would you be willing to use the C version of the CEF API only?
- Would you be able to accept the limitations and potential headaches (outlined above) of X-Plane-determined CEF versions and compatibility?
If you don’t mind telling me a bit about your intended use cases, that’d be very helpful as well!
EDITED TO ADD: There’s a third option here that I didn’t consider: X-Plane could provide a “wrapper” around CEF that offers “just” a browser surface, and simple interfaces like the ability to change the URL programmatically. This has the advantage that we could update CEF regularly without breaking the API (though there’s always the risk that a new version of Chromium would change how it handles your HTML + CSS + JS). The disadvantages are twofold:
a) If a plugin developer really, really needs the full power of the CEF API, they’re out of luck (or we’re back to square one with respect to having to disable core X-Plane functionality in order to support the plugin).
b) New XPLM APIs are a massive tax on our development time. Every time we need to make a change, we have to go test a dozen plugins… then go through an extensive beta… then inevitably hear about a show-stopping bug we introduced three hours after a release goes final. 😀 In contrast, providing a (major-version-stable), transparent copy of CEF costs us very little dev time; time that would otherwise be spent maintaining the XPLM API can be spent on, like, major features.
* Aside: This is actually how we test a lot of new tech in X-Plane: we find a single, relatively out-of-the-way place to make use of it, ship it in a major version update, and wait to see if it blows up. Betas catch a lot of bugs, but not all, so this is a way of hedging our bets when it comes to code that hasn’t been battle-hardened. This is how we worked the bugs out of the user interface framework (Plane Maker’s panel editor was the testbed), the X-Plane 11 particle system (behind the scenes, it was used for some very minor effects in X-Plane 10.51), and more.
I believe many are working on versions of a virtual electronic flight bag, as standalone or part of aircraft – which is what the ff320 could be considered, and to which this would be a feature. Your use is very limited so you would be holding back development. I think a decent API interface in a must.
Uh… so you’re voting for just disabling core features in the presence of plugin-provided CEF?
1) Are you currently, or are you planning to use CEF in the future?
Yes FlyJSim is definitely working on this and looking to incorporate CEF. What is holding us back at the moment is our desire to be a good denizen within X-Plane eco-system. I think the need for CEF will be huge once we arrive at VR. Over the years the typical use case for charts has gone from having a printer on the desk where one prints out charts to pulling them up on an iPad or second monitor using Navigraph / ForeFlight, and once the VR headset is donned you are going to need a virtual screen to pull them up on. 🙂 Exciting! But we also have multiple addons planned outside of the cockpit that would benefit from in-sim connection to the internet.
2) Would you be willing to use the C version of the CEF API only?
Absolutely! C is a lovely language, lets not be too picky here. 🙂
3) Would you be able to accept the limitations and potential headaches (outlined above) of X-Plane-determined CEF versions and compatibility?
Yes.
I believe the BEST solution for this would be for Laminar and Flight Factor in particular (who are already shipping a CEF plugin), along with the rest of us who have been working on it, to have an open source repository. No need for Laminar to do all the work, but its important that Laminar have control over what stable version ships.
It is true that the CEF api would evolve over time, but I don’t believe addon developers are going to be held back by that. And I would tend to say that its the lack of insite as to api changes that is typically the bigger concern as an X-Plane dev than the actual changes. Again, having it be an open source project hosted by Laminar would really improve that by creating clear and open communication.
Thanks Tyler so much for this blog post and for moving the ball forward on this.
Also, I love the post title. Very witty.
1) Are you currently, or are you planning to use CEF in the future?
AFM is considering integrating CEF into our add-ons in the future. What is holding us back is the global plugins that are essentially making people choose which add-ons to have. With CEF in the A320 always being installed, we are limited in what we can do. If there was a global X-Plane native install, it would allow much more flexibility and not have a limitation on one add-on at a time having CEF.
2) Would you be willing to use the C version of the CEF API only?
Of course. Whatever would be required to get it to work.
3) Would you be able to accept the limitations and potential headaches (outlined above) of X-Plane-determined CEF versions and compatibility?
Yes, I don’t think many devs that can’t update their code would be using CEF much anyway.
Having a native modern web browser integrated into X-Plane would be absolutely killer. My only concerns are:
1) The browser MUST be kept up-to-date. Browsers run pretty hostile code all the time and having an outdated browser in X-Plane just makes it into a rather easy to use malware vector.
2) Do NOT expose the CEF API to plugin authors. Instead, provide a minimalistic simplified API to just: a) draw the browser at some place in the cockpit, b) point it at a URL and c) register some custom JS callbacks. Basically keep it simple and don’t give plugin authors too many ways to poke themselves in the eye with it. That way you can keep the backend always up to date with CEF’s changes while not having worry about breaking plugin compatibility.
Basically I think that security and plugin compatibility are “must have”s. I’m willing to sacrifice flexibility to interact with the browser from code to get these two problems addressed.
Many people deactivate security software when running X-Plane to squeeze out the last drop of performance from their CPU. Implementing and maybe opening a browser to all URLs then would mean to expose the user’s sytem to the “dirty internet”. Also all major browser devs are fighting hard to patch their software within short cycles. How could this be done with CEF when long term versions are required to not kill add-on software for X-Plane?
I agree with Saso and I think CEF is the entry to a dangerous path…
Just my 2 cents…
Regards,
Marc
I think the really scary scenario is:
– User runs x-plane with admin privileges.
– X-Plane runs CEF
– CEF runs malware that breaches barrier from browser sand box to host app and
– By transitivity malware noms your system.
Two things to note:
1. For the love of all things made of salt, DO NOT EVER RUN X-PLANE WITH ADMIN PRIVILEGES.
It is never necessary to do so.
It doesn’t help.
It usually screws things up.
It’s really dangerous. We do NOT audit our code to ensure it’s safe under admin privileges.
2. There’s perhaps a difference between running CEF and running CEF with arbitrary external URLs. One use of CEF is to simply build UI out of local HTML, e.g. HTML+CSS = x-platform UI kit. We aren’t really encouraging user to go surfing the web INSIDE x-plane.
(Although it’s likely someone would want that for VR purposes…and now the wide web is inside X-Plane.)
Whether X-Plane is run with admin privileges or not, and let’s face it – if you’re the only user of a system, you’re an admin, any expansion of X-Plane’s ability to access the web natively is not something that warms my heart.
Not wanting to stomp on progress or be Negative Normie, but: 1. I do not want this feature. 2. I do want the ability to disable it, smash it, kill it, neuter it and/or to grind it into fine subatomic dust if I have no choice but to kneel before my executioner (script kiddies).
There are too many a*holes in this world that can and will pervert spiffy web utilities and “nom a system” just for the fun of it. The stated purpose of the integrated browser simply to access the website so that one can make an in-sim purchase of X-Plane is just not worth the risk. Fluffy nonsense. (Sorry, Tyler!) And eventually expanding this so that just anyone can integrate web access into a plugin is blinding scary. Here’s where you get my vote (“none of the above”) to utterly set this aside and concentrate limited manpower on X-Plane 11 features that are not done. Like the Plane Maker interface, and most especially to update all of the crude, ancient instrumentation that builders use to create new aircraft. And the real list is super long.
Ben – clearly you guys are aware of the really scary scenario. Having realized what *could* happen, there’s no real way I can understand why you’d even consider moving forward with this integration. It’s kind of like Jurassic Park. Just because you *can* do a thing, doesn’t mean you should. 😉
And I’ll add this – since clearly CEF can already be added by third parties: While I don’t like that either, at least with an honest add-on where I have a choice of whether or not to integrate a web browser via plugin I can make my own decision whether or not browser code is in my beloved flight sim. I run a naked sim in a dedicated cockpit PC with zero antivirus. It has web connectivity that is only used to update X-Plane. Presuming the updater doesn’t get hacked, I’m not exposed to the same risks I would be if I used the system to browse the web. The system is off any time other systems are in use – potentially on the web. Those systems are heavily protected. If I could update the cockpit with a downloadable patch, I would airgap the thing.
To “grind [… CEF] into fine subatomic dust” is what I recommend to do within X-Plane. Tyler’s post already opened Pandora’s Box making people want this – be it for VR or silly toys implemented to add-on aircraft like the FF A320. For now it may be a dangerous toy and later on it may become a dangerous mandatory item for i.e. some stupid DRM stuff.
The day it will be used for such stuff like DRM features, CEF will be mandatory to run that kind of add-ons. By then we’ll pass a point of no return. I really recommend to stop CEF before it is too late!
Just like Steve I really don’t want this and at least request a chance to disable CEF or (even better) prevent the installation of it. However, if 3rd party devs start playing with it, killing CEF per user may then limit the portfolio of usable add-ons.
Also, if the major idea behind it is to improve the ease of purchasing the demo, why do you need CEF? Just like tons of other software, a link opening a browser like i.e. Firefox or Chrome also would do the trick – but then under full control by the user!
Also I recommend to not think of VR being the excuse for everything. VR is not required for online shopping. Although I understand that VR fan boys are looking for a way to break the barrier, I pretty much believe that reading complex charts while taxiing or flying through their VR headset is really not a great idea…
Regards,
Marc
>>Are you currently, or are you planning to use CEF in the future?
I am using it in FFA320.
>>Would you be willing to use the C version of the CEF API only?
No, because i am using custom rendering application and custom CEF builds with some fixes and extensions.
>>Would you be able to accept the limitations and potential headaches (outlined above) of X-Plane-determined CEF versions and compatibility?
No, CEF will be a part of FFA320 as is, beacuse it’s deeply integrated in the internal infrastructure and requires alot of time to change something.
I hope you will not leave thousands of FFA320 users with broken plane.
Can you tell me more about how the plugin uses CEF, and the extensions you’re using?
1. Patches to force CEF/V8 work inside the XP and initialize\deinitialize everything correctly with plane\XP loading\unloading sequence.
2. V8 is natively (with it’s own API) integrated across all of the aircraft objects and platform.
3. Patches to get access to native V8 contexts.
4. Patches for resources\cache paths mechanics in CEF.
5. Patches for pure hardware (GPU) pages rendering in CEF.
6. Integration in panels rendering system with hardware rendering extensions.
7. Custom rendering application with shared memory interface to aircraft objects and JS contexts manipulations for aircraft object access and browser functions.
8. Some patches to implement browser tab in the EFB.
9. Cross platform (different simulators) integration architecture with same CEF integration code for all platforms.
Just from memory. I can’t see any way how to resolve this clearly…
As i can say, working with CEF for years, this is not a very smooth thing. It’s changing frequently, and maintaining required patches is time consuming, and some times, very difficult. I am not really sure, that you need to integrate it in the XP.
We still have alot of problems with it, but this is not a critical things, because only EFB requires fully working CEF, and it’s can be accessed with external browser in case of some malfunction.
So, making something critical based on the CEF is not a very good idea. It is good, when it’s working only as a toy.
There already was a plugin (few years ago) implementing CEF integration for XP, and no one used it, as i know. You can try to find this in org forum.
>>> I hope you will not leave thousands of FFA320 users with broken plane.
But this will mean over time that thousands of FFA320 customers will have to fiddle with moving/disabling plugins in order to run other aircraft and addons within their sim.
I do not expect a lot of other plugins using CEF, this is a very problematic thing. Ofcourse XP devs can cut some corners, solve some things for other devs… but really, i can’t imigine how this will work.
As i wroted above, there already was a plugin for CEF integration, and no one used it.
Since this is a survey, I would like to ask something as the developer of the plugin FSTramp. Will plugins be able to define hotkeys for the X-Plane command system in the future? Some plugins need hotkeys, but XPLMRegisterHotKey is not integrated into the current X-Plane user interface. Also, plug-ins relying on XPLMRegisterHotKey can not offer their users joystick buttons. The situation is frustrating.
Last year I had already sent a suggestion for 4 additional API functions to Jennifer, unfortunately without reaction.
You can register commands, which users can bind to either keys or joystick buttons. See XPLMCreateCommand() and XPLMRegisterCommandHandler() in XPLMUtilities.
These facts are known to me. However, 5 out of 6 users will immediately delete the plugin installed for testing if they have to perform a hurdle of parameterization before use. This is not reasonable for the user and puts the manufacturer in a bad light.
Is it fine to hijack the post and ask about the particle system (hey, you brought it up, not me!) and ask if it’s come any further? 🙂
I’d recommend using Webkit instead, as it’s pretty lightweight, cross-platform and easily embeddable.
If you however, remember to tell it to disable the loading of plugins because it WILL load a ton of memory hungry crap if the user have configured a lot of Firefox plugins on his system. This is perhaps true for the Chromium kit as well, I wouldn’t know, but definitely something you’d want to check out.
I will be releasing a general purpose addon updater / web browser in the next few months. Here are the necessary features it uses from CEF:
* V8 integration
* Manage downloads via CefDownloadHandler etc
* Custom resource handlers
* Offscreen rendering, like probably everybody else is using
>>Would you be willing to use the C version of the CEF API only?
Yes, if this is the only option.
As you said in the post, the C API has significant drawbacks. You mention that this makes memory leaks much more common- a possible downside might be that plugins using CEF have more stability issues / memory leaks, resulting a worse X-Plane experience for people using these plugins.
>>Would you be able to accept the limitations and potential headaches (outlined above) of X-Plane-determined CEF versions and compatibility?
I am fine with the current version of CEF for now; however, who knows what features will be added to CEF in the future?
>> That means X-Plane would be stuck at a fixed version of CEF for at least the lifetime of a major version to prevent breaking plugins.
You mention waiting a couple of years for new features as a downside; I think waiting a couple of years for security fixes is perhaps a larger downside.
Shipping a fixed version of CEF is not a responsible thing to do for security reasons. What is the plan for addressing vulnerabilities in CEF? How do you protect users from these vulnerabilities being exploited, especially if you can’t update CEF?
>> There’s a third option here that I didn’t consider: X-Plane could provide a “wrapper” around CEF that offers “just” a browser surface, and simple interfaces like the ability to change the URL programmatically.
This would not work for my use case at all, as it lacks critical features like V8 integration.
Have you considered integrating another browser to solve some of these issues? Webkit, Servo, etc.
I am all for an embedded browser API so I can give the Anti-VR brigade a good answer for the “but how do you… in VR”.
I certainly would be happy to make use of it in XSB to encourage individuals to update when I get new releases out.
Heck, even a non-UI http fetch method would make me very happy and let me purge a chunk of code from the codebase.
I may even be interested in the full CEF API later if I move onto other areas of plugin development.
I am not impressed by the “Oh, but we did it first, don’t you dare break our plugin” type responses from the other developers – we’re simply riding on the platform that Laminar has produced – if they will provide common functionality, then we should embrace that and build upon it.
If they want to include a specific framework, then we should step out of the way and let them, and resolve the issues we face ourselves.
Forcing Laminar to produce silly workarounds because we’re too lazy to move with the change benefits nobody and simply leads to the house of cards problems I see far too frequently in modern software engineering – where a serious of perilous hacks built on top of other hacks stands for too long, and becomes ultra-fragile when the foundations change with time.
“Are you currently, or are you planning to use CEF in the future?”
No
Would you be willing to use the C version of the CEF API only?
No
Would you be able to accept the limitations and potential headaches (outlined above) of X-Plane-determined CEF versions and compatibility?
No
Allow me to explain my answers, I’m not a programmer per se. But I spent a career in networking and corporate Internet security. And this implementation of CEF bodes nothing well. True, it would be useful, even spiffy as a feature as an expansion of the rear world into the virtual. But I cannot stress strongly enough how this opens up a user system to a host of unwanted problems.
As Ben already posted, The downside far outweighs the potential upside. This Is the 1st feature addition that honestly makes the Hairs in the back of my neck stand up. Any system That can be exploited most assuredly will be exploited. There are just too many people out there with nothing better to do than hack into systems using any exploits available. And this would just be too much of a potential security breach.
It’s a can of worms best left closed, or at the very least left for others to implement on an as-needed basis giving full control of its addition and implementation to the end user.
Please do not make CEF mandatory. As others pointed out, it opens a big Pandora’s box with security concerns. And are you really sure you can ship security updates on time?
Are you currently, or are you planning to use CEF in the future?
I use it with the FFA320. I would not want this to break!
Would you be willing to use the C version of the CEF API only?
No
Would you be able to accept the limitations and potential headaches (outlined above) of X-Plane-determined CEF versions and compatibility?
Absolutely not.
Is the CEF browser / plugin secure? If it is how can I tell? I use a malware app that locks down my browser instance the second I use a banking app or online store. I’m guessing it will not be able to do that with this plugin.
Why are you even thinking about this when there are so many other things that people are crying out for? I have never seen one post in the forums that say’s we need this functionality.
So, what is the progress on improving the frame rate of the sim in general? I think this is way more of concern by many….
X-Plane 11.20, like all other updates before it in the v11 run, brings a new piece of our effort of modernizing our rendering engine towards better performance. We’ve improved the performance of X-Plane quite a bit over the past couple of updates and we intend to continue this in the future! So if you are wondering what the progress on that is, just compare 11.00 vs 11.20. Of course 11.20 is not the end of our efforts to improve performance, we still have plenty of things to optimize and of course Vulkan is in the works as well.
However, I don’t think that means that everybody in the company needs to exclusively focus on performance and that we can’t discuss other new things for X-Plane. If you have concerns about framerate regressions of a particular update, we always appreciate bug reports and repro cases!
I use Windows on a Ryzen 1800X
“However, I don’t think that means that everybody in the company needs to exclusively focus on performance and that we can’t discuss other new things for X-Plane.”
In a given situation I had 25 fps, reason: XP was CPU bound
Accidentally I started a second instantiation of X-Plane (inside the second desktop) and this instantiation has a drop a 3 fps only, but – of course – was cpu bound also.
And still a lot of cpu power was unused!
For info, just discovered that the CEF directory is more than 700MB… With no graphic assets contained in there, the added software complexity and bloat seems frightening… Not sure I would like to keep this for gadgetish side-functionalities, not even talking about being a gateway to net malware…
Are you sure? On my installation (current beta, windows 10) CEF folder is “only” 173mb. But, yes, still quite a lot…
Allow two non-dev questions please…
(I didn’t read the other replies, sorry don’t know if mentioned)
1) Aren’t there other web API to use instead of CEF and its problems? (webkit?)
2) I forgot #2. (really)
Hi,
I would like to add my thoughts to this thread, and these are only my opinions.
As a casual programmer and simmer I find it hard to believe that an implementation of CES will make the simulation better, there are other features I’ll appreciate to be implemented first.
Let’s face it, right now it is only done for internal purchasing and later who knows.
I side with those who do not need a bloatware in their sim, and I believe, although it is mainly from hearsay, that to manage CES is not an easy task, both in short and long run, so why waste all that time and energy?
My suggestion ?
Instead of implementing a browser, maybe implementing something simple as web engine, to act as a broker between services. My meaning is, we need a lean and mean service that just sends, for example, requests (in XML format) to some service and it receives a respond in the form of XML (or other) and then XP will decide what to do next. There is no rendering on the client side and hopefully XP web broker will be able to filter what requests or responds are legal or not (so no malware or staff like that).
Plugins can be exposed to this API to do actions similar to these, but there is no rendering on the client side, someone will have to write the code to display the incoming information.
Last, I know that everything today is connected, but I’m not sure it means that X-Plane should become a do it all application with so many compatibilities issues to wrestle with.
Good luck Laminar with what you will decide, at the end it will be the programmers and simmers that will eat what you will bake 🙂
Cheers
I wholeheartedly agree with this. Aside from the security issues, implementing a full fledged web browser inside XP with the added cost of CPU + memory in order to leverage at best a 10% of the funcionality seems to me as “killing flies with cannons”. I would first collect, investigate and review what Laminar and 3rd parties developers would want to do with it and then come up with a simpler, custom solution.
1. Are you currently, or are you planning to use CEF in the future?
Not yet, but we are planning to use it in future.
2. Would you be willing to use the C version of the CEF API only?
Yes.
3. Would you be able to accept the limitations and potential headaches (outlined above) of X-Plane-determined CEF versions and compatibility?
Hard to answer without details but most likely yes.
I’d vote for exposing unstable C version CEF API *plus* minimalistic stable API in XPLM for basic high level tasks so plugin dev can choose which approach would like 🙂
I think adding a web browser to X-Plane is complete nonsense, especially if the only purpose is to upgrade from the demo to the full version. That’ll be one time in the life of X-Plane. Despite of just adding useless code that has to be maintained, X-Plane does exchange too much data already now (without declaring that or giving the user the possibility to disagree on it).
(I hope WIndows 10 isn’t the model: It just downloads several gigabytes without telling you, or without giving you the ability to reject that)
Please: It’s still my computer, not a member in an X-Plane bot-net.
I’m afraid you are wasting resources on the wrong features.
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
The new APIs are shipping in the latest beta. I’m going to get the docs updated today.
More than a web client I’d strongly suggest to implement a web server that could let developers to make a connection using mobile devices and let users to manage board instruments (FMC as first, then possibly even others).
My thought is that anything that opens the sim, to a potential security threat, needs to be seriously looked at from the absolute worst case method. This opens computers to a potential new attack method. I get that you want to make it simple for folks to get the sim etc the trade off of an increased security threat, and the potential blow back from it should be enough to make you really think. The risk here, doesn’t outweigh the reward.
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.
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.
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:
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.
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/
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.
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.
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.