[Feature Request] - Add various interfaces (CLI, API, SDK) to communicate with the VDF.Core module

[jeffward01]

Environment

• OS: Any

Describe the solution you'd like

Intro This is a fantastic tool - big thank you to all the developers and contributors who participate and open up Issues. It is very cool of you!

Request

It would be very cool to see this code 'extracted' and made a bit more modular so that users can work with the code in various ways, including (in no particular order):

• 1.) API interface
  • A user can interact with the software from an HTTP api of sorts (Like many of you, I prefer a REST API in comparison to RPC)
• 2.) RPC Interface
  • This is 'classic' as many torrent clients have an RPC interface. I suggest this only because it seems to be favorable for the torrent clients, I am not sure why. Perhaps someone can enlighten me. But this is a popular mode of interaction
• 3.) CLI Interface
  • For obvious reasons this would be very helpful
• 4.) SDK C# interface:
  • Would be very cool to be able to extract this into a nuget package so it can be included in other libraries as the 'Core Module'
  • I understand that perhaps, the code would have to be modified to eliminating 'locking' or freezing. Converting the code to a more async - SDK friendly sort of behavior

[0x90d]

For something like that the core module must be a separate github project you can reference to and ideally also a nuget package. I don't have plans for that and I may integrate the core into the GUI in the future.

[jeffward01]

Thats cool, this is something that is on my list of things to do and create a PR for (or new repo) I think this will be a very cool thing to have

[strazto]

Coupling GUI to core

@0x90d

I don't have plans for that and I may integrate the core into the GUI in the future.

Please don't do that, there's not really anything to gain by coupling the engine to a particular frontend, and a lot of people looking at this tool are particularly interested in headless media server deployments, scriptable applications, etc.

Interface discussions

@jeffward01

API Interface

Yeah, this would be nice, a "server" mode. I actually began implementing something like that in the fork I used to maintain https://github.com/strazto/videoduplicatefinder ( @0x90d had been inactive for quite some time) , I made pretty decent progress, but then @0x90d returned to maintaining this project made massive architectual changes to the upstream (the current repo), making my changes moot, so I stopped maintaining it.

If I had spare time, I'd consider forking this repo and making something similar on it, but I'm still a bit disheartened by my wasted effort last time I tried to contribute, so I'd at least wait for @0x90d to confirm they're willing to accept contributions on this project.

CLI Interface

This actually used to have that, it didnt support any convenient structured output (html only), I made a PR requesting JSON - https://github.com/0x90d/videoduplicatefinder/pull/136 , but it was rejected for the same reason as before

I'd suggest starting here, and maybe looking to the old v2 implementation for a general outline. It should be a bit easier to get something useful off the ground. If you do this, I request you add the option to emit some easily deserialized format, like JSON.

Off topic:

@jeffward01

2.) RPC Interface ... . I suggest this only because it seems to be favorable for the torrent clients, I am not sure why. Perhaps someone can enlighten me.

There's quite a few different RPC protocols out there with various advantages and disadvantages, and the old ones don't tend to be that nice to use.

I think their popularity came down to less overhead (sometimes) more structured specs than REST apis, and sometimes API invocation can be abstracted to have a more "native" feel.

I'm pretty sure the RPC interfaces that are seen in torrent clients these days are just holdovers from whatever was popular back in the day, since the more popular torrent clients are actually pretty old.

There are popular modern RPC protocols / implementations that seem well-regarded, notably gRPC, https://grpc.io/ , originally developed by google before open-sourcing. I'm pretty sure gRPC is known for having very good performance compared to other remote abstractions.

[0x90d]

Please don't do that, there's not really anything to gain

Actually there is, it would allow me to publish as single executable (#161). Because right now the github action script fails when trying to publish as single file due to having two projects and I dont have the github skills to fix that otherwise. And it would get rid of having to duplicate each setting.

[0x90d]

I don't have any plans nor time for this. Anything like that can be done via a fork if necessary.