Shut down crossbar from guest worker (browser)?

#1

I would like to use crossbar for a desktop application, but instead of requiring the user to open a browser and navigate to localhost, it is easy enough to configure the browser as a crossbar guest worker. Stopping the application, however, requires two steps: Ctrl-C the console to stop crossbar, and then closing the browser.

Is there a more user-friendly way to start/stop desktop applications with crossbar?

An obvious approach would be to write my own twisted app to start crossbar and the browser as separate child processes, and then use a looping call to continuously check the browser pid. But running an external reactor just to watch for the browser to close sure feels like alot of extra baggage.

0 Likes

#2

Not sure if I get it: you want the user to start a Crossbar.io node, which then starts the app UI by launching a Web browser as a Crossbar.io guest worker. And when the latter worker exits, you want the whole node to automatically shut down, right?

If so, I think a clean way to expose this would be via an option in the guest worker configuration like “restart = shutdown_node” - that is as a specific “restart” policy for the worker.

??

···

Am Sonntag, 1. März 2015 22:28:15 UTC+1 schrieb johnt:

I would like to use crossbar for a desktop application, but instead of requiring the user to open a browser and navigate to localhost, it is easy enough to configure the browser as a crossbar guest worker. Stopping the application, however, requires two steps: Ctrl-C the console to stop crossbar, and then closing the browser.

Is there a more user-friendly way to start/stop desktop applications with crossbar?

An obvious approach would be to write my own twisted app to start crossbar and the browser as separate child processes, and then use a looping call to continuously check the browser pid. But running an external reactor just to watch for the browser to close sure feels like alot of extra baggage.

0 Likes

#3

Yes, your description of the use-case is correct.

With a “shutdown_node” feature, I could create a Crossbar.io application that looks to users like a standard desktop application.

  • I would provide an alias for users to start the application, which would internally start Crossbar.io, including the browser as a guest process. (Actually, since I have to do this on Windows, I would create a desktop shortcut instead of an alias. Also, for what it’s worth, the browser executable would be a customized/stripped-down version with no tabs or navigation features, so that it only runs the designated application, as set in the guest worker arguments.)
  • And when the user closes the browser, the entire node exits, so that the application is shut down with all Crossbar.io processes terminated.
···

On Sunday, March 1, 2015 at 4:50:58 PM UTC-5, Tobias Oberstein wrote:

Not sure if I get it: you want the user to start a Crossbar.io node, which then starts the app UI by launching a Web browser as a Crossbar.io guest worker. And when the latter worker exits, you want the whole node to automatically shut down, right?

If so, I think a clean way to expose this would be via an option in the guest worker configuration like “restart = shutdown_node” - that is as a specific “restart” policy for the worker.

??

Am Sonntag, 1. März 2015 22:28:15 UTC+1 schrieb johnt:

I would like to use crossbar for a desktop application, but instead of requiring the user to open a browser and navigate to localhost, it is easy enough to configure the browser as a crossbar guest worker. Stopping the application, however, requires two steps: Ctrl-C the console to stop crossbar, and then closing the browser.

Is there a more user-friendly way to start/stop desktop applications with crossbar?

An obvious approach would be to write my own twisted app to start crossbar and the browser as separate child processes, and then use a looping call to continuously check the browser pid. But running an external reactor just to watch for the browser to close sure feels like alot of extra baggage.

0 Likes

#4

This is a very specific use case. Now that we've discussed it, I added

https://github.com/crossbario/crossbar/issues/263

Don't hold your breath .. my queue is overfull=(

Cheers,
/Tobias

···

Am 01.03.2015 um 23:31 schrieb johnt:

Yes, your description of the use-case is correct.

With a "shutdown_node" feature, I could create a Crossbar.io application
that looks to users like a standard desktop application.

0 Likes

#5

Yes, I suppose this is a special case, nevertheless, thanks for adding a feature request.

I can appreciate your position, so I’ve been looking at the Crossbar.io code, mostly the controller directory, to see if I can implement something in on my own. If you have any thoughts on how to approach this, or where to start, I would appreciate any guidance you have time for.

···

On Monday, March 2, 2015 at 10:19:49 AM UTC-5, Tobias Oberstein wrote:

Am 01.03.2015 um 23:31 schrieb johnt:

Yes, your description of the use-case is correct.

With a “shutdown_node” feature, I could create a Crossbar.io application

that looks to users like a standard desktop application.

This is a very specific use case. Now that we’ve discussed it, I added

https://github.com/crossbario/crossbar/issues/263

Don’t hold your breath … my queue is overfull=(

Cheers,

/Tobias

0 Likes