Best practice for starting/stopping a helper app?

[DFBurns]

I'm working on a plugin that relies on an external command-line app to do some work. This app's start up time is about 2 to 3 seconds which is not responsive enough for me. (My plugin puts up a dialog box and when the user presses Ok, I want to see results as fast as possible.)

So, I've set things up so this app can be run as an HTTP server that waits for requests rather than quitting each time. When I POST to it from Lightroom, results come back almost instantly. Great.

I'm now thinking about strategies for when to start this app in the background and when to shut it down and I'm wondering if others here have past experience, advice, best practices, etc. about how to do this robustly within the Lightroom plugin environment.

I've done some experimenting with entries in Info.lua:

Using LrInitPlugin, I can see my init script run when Lightroom starts and if I reload from the plugin manager. My plugin already defines custom metadata so I didn't need to use LrForceInitPlugin. I'm not sure how confident I should be in this though. When I first added the init handler, it didn't run even after reloading in the plugin manager. I had to restart Lightroom entirely. Things seem reliable after that but now my confidence is not 100%.

I wrote a handler for LrShutdownApp. This seems to run reliably when the Lightroom app is ending. I could tell my HTTP server to quit here. Is this 100% reliable?

I've tried LrEnablePlugin/LrDisablePlugin. These seem reliable (once I restarted Lr like my init handler above).

I've tried LrShutdownPlugin. This seemed to run reliably when I reloaded from the plugin manager.

I'm wondering if this is the best strategy:

- Since my helper app is heavyweight and a user may not even use my plugin most of the time, don't start it every time Lightroom starts. Instead, every time the plugin needs the helper app, if that HTTP POST fails to connect, launch the app, wait for it to start up, then retry the POST. In this case, the first use of the helper app is slow.

- To make sure the helper exits, try to send it a command to quit inside LrShutdownApp. In rare(?) cases that doesn't work, implement a timeout in the HTTP server of the helper where, if it hasn't received a request in X amount of time, exit.

Thoughts?

db

[DFBurns]

Quick add-on question:

What is best practice to pass around between scripts the handle or object that contains the helper app's info? Should I just stuff things into _G or is there another way considered to be a better approach?

db

[johnrellis]

What is best practice to pass around between scripts the handle or object that contains the helper app's info? Should I just stuff things into _G or is there another way considered to be a better approach?

I've used that approach in a number of my plugins -- it's simple and doesn't have any downsides that I've encountered.  _G is specific to your plugin and persists until LR exits or your reload the plugin.  I use it for maintaining caches of information that's relativel expensive to laod, copy/paste buffers, the number of instances of a floating panel that are open and a handle on that panel, history state, a queue of photos to be processed in background, mutexex (locks) to avoid very obscure SDK bugs and infelicities with concurrent tasks, etc.

I use "strict.lua", so to avoid it complaining about accesses to an undefined variable, I use this idiom to "declare" a global variable with an initial default value.

var = rawget (_G, "var") or default-value

[johnrellis]

My plugin already defines custom metadata so I didn't need to use LrForceInitPlugin. I'm not sure how confident I should be in this though.

I use the custom-metadata approach in a couple of my plugins and haven't experienced any issues (over many years).

[johnrellis]

- Since my helper app is heavyweight and a user may not even use my plugin most of the time, don't start it every time Lightroom starts. Instead, every time the plugin needs the helper app, if that HTTP POST fails to connect, launch the app, wait for it to start up, then retry the POST. In this case, the first use of the helper app is slow.

- To make sure the helper exits, try to send it a command to quit inside LrShutdownApp. In rare(?) cases that doesn't work, implement a timeout in the HTTP server of the helper where, if it hasn't received a request in X amount of time, exit.

That sounds sensible to me.