Hi,
One of the benefits of the extcap-cli is, that we can and currently do, send an API version to the extcap utility which would allow breaking changes while still enabling a compatibility mode for older versions. Because of that, I think 2 would be an ideal scenario, just define the response to the API call.
1) is not an option. We have extcaps implemented in C, Python, Powershell, Delphi, Go, I even know of one implemented as windows batch script. Only a limited version of them would be able to implement the window reliably. Also, the general idea for extcap utilities is, that they are universally usable across platforms, this dependency is a bit too much.
So it is either between 2) or 3) and from my POV we should choose the option the promises to be more reliable, no matter about changing the extcap side of things.
One thing though. Whatever the solution, we should try to provide a „don’t care“ mode. Otherwise most developers will have to die be into cross-Plattform development stuff, and as most external extcaps I know about are written by sysadmins or internal devs for very specific usecases, I fear that might turn people off from using the api in the first place.
You mention one point of view I missed - many different languages/tools
to create extcap. I think that in this case 2) is the only option.
In addition, I'm afraid that 2) should be used for *nix systems and for
Windows too.
Now we use 1) for *nix systems and we are thinking about 2) for Windows.
Even it was clear and OK to me before, now I see it as too complex - two
approaches, based on OS.
I know that 1) (signals) is common in *nix world and we can use it, I
think than new approach should allow us to use it in any OS.
Best regards,
Jirka Novak