Electron master extension

[bogthe]

Signed-off-by: Bogdan Stolojan petre.stolojan@arm.com

This PR fixes: #3364
By adding a new extension method called backendMasterElectron to modules which will be required into node inside of the master electron process and enabling packages like electron-updater to work with Theia.

@kittaakos @marechal-p Sorry I rushed and messed up the previous PR (#3431) so badly 😅 .

Reopening it here and addressing your previous comments. 🙇

[bogthe]

@kittaakos going back to naming, I used master because of isMaster check on the cluster.
How about electron-main-process?

[bogthe]

@marechal-p, quoting your reply on the previous PR:

@bogthe I wasn't talking about the communication FE/BE, but rather the way they are constructed using inversify's container modules, which allows for contribution providers and symbol rebinding.

Currently the only way to extend the way the electron app part feels is by changing the generators, in the main repo. Another solution would be to forget about our generators and create your own. That could be different, that's my point.

I see, I think next it would be an easier / nice improvement to use inversify for this type of packages and have them in line with how the others work. If our requirements diverge more with theia's project roadmap implementing our own generators is definitely the way to go.

[akosyakov]

@bogthe It was already decided to use inversify for customization. New entry points should be aligned with it.

//cc @svenefftinge

[svenefftinge]

I agree with Anton, that we should keep it symmetric for the sake of simplicity. Does that work for you use case or would using inversify here as well cause any trouble?

[bogthe]

@svenefftinge I don't think it will cause any trouble, I'll have to look at how JsonRpcConnectionHandler and WebSocketConnectionProvider pass messages and probably add bit more changes to the generated files.

[bogthe]

Now using inversify for this entry point. Only thing needed is a way to trigger / access these modules.
@svenefftinge I would like some guidance around that if possible 😄 , what's your opinion on the following:

• Have a thin wrapper around ipcMain, ipcRenderer that will allow messages to be passed between FE and BE. Preferred because it's relatively easy to implement and any FE package can use it;
• Or have the same setup for these type of modules similar to back-end application, i.e. a server listening for at a specific port etc. Seems like a bit more work and integration with the code base.

[akosyakov]

@bogthe just to clarify that we are on the same page

the process structure looks like:

• frontend: electron main process -> electron renderer process
• backend: electron main process -> (server master process ->)? server worker process

You want to hook into electron main process to run electron-updater there and be able to talk between electron main and electron renderer processes?

This PR provides an entry point for server master process, not for electron main. Are you sure it is what you need? Should not this PR provides an entry point to electron main process by instantiating a container within electron-main.js file?

After that you can create an extension which contributes to electron main and frontnend electron entry points and establish communication via ipcMain or ipcRenderer. electron renderer process (FE) can communicate already with server worker process (BE) over JSON-RPC

[kittaakos]

I propose closing this PR in favor of #8076.

[westbury]

I propose closing this PR in favor of #8076.

This PR was opened while @bogthe was working on Mbed Studio. I tried to build Mbed Studio with #8076 to test it out but it would have taken a lot of work. However this PR is clearly obsolete in view of #8076 so I'm closing this one.