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
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
