Make Neolink a Library?

[QuantumEntangledAndy]

Just thought I'd discuss this.

But I was thinking of possible new features for neolink. Things like mqtt for command and control and a fuse system to mount the SSD recordings from the camera. Although these would be cool I am not sure they fit the scope of neolink as the rtsp bridge.

Could we work towards breaking neolink into:

• neolink-core which holds all the camera core details and commands
• neolink-rtsp which uses neolink-core and provides the rtsp it currently does. Call this binary neolink for backwards compat
• neolink-mqtt which allows command to be send to the camera over mqtt
• etc etc

[twistedddx]

I think neolink-core would be a great contribution to the Reolink/BC community.
I personally have no immediate intention to do anything with it, but numerous people have had various attempts at developing something for these products.
There is requests for a Linux client and a general 3rd party client.
There is more integration potential for these cameras.

A library may make several more projects a reality.

[QuantumEntangledAndy]

I think it would be great too, and would make building third-party software easier without us all reinventing the same protocols.

We can open it up to rust projects quite easily and make it a crate.

I think eventually a general purpose C library would be good but this would be a bit more work as we'd need to build a C interface and my C is quite rusty.

[entropin]

Yes, I already have two project that will benefit "neolink-talk" for one.
But also a project i started yesterday when i got stuck with talk. A "toy robot" code for my kid that makes E1 reacti to voice, track your face, nods and blinks using its led's

So neolink-core whould be grate.

[QuantumEntangledAndy]

@thirtythreeforty Would you be in support of these sort of changes? If so I'd like to write up a PR but it will likely be a lot of changes as it will more the project over to a workspace like setup

[thirtythreeforty]

Yes, would be in support. A couple comments:

• I'd like to target native Rust client code first, and not (yet) focus on a stable C API. That said...
• C is the lingua franca of most inter-language projects, so
• It's worth considering how a stable C API will be layered on top, to avoid footguns when we inevitably want to add that.

I would avoid splitting the binary at this point, because it becomes difficult for users and developers to manage a gaggle of services (I do this at $dayjob and I'm trying to reduce the number of services we have). So then the architecture becomes:

• neolink-core which holds all the camera core details and commands. Strictly an idiomatic Rust API
• neolink the binary, which links to neolink-core and Gstreamer and provides a CLI, service, etc.

[QuantumEntangledAndy]

I think we are mostly on the same page about this, certainly target rust first making a solid crate that can be used in other rust codes.

I am thinking for core to contain the the needed data structures methods to serde and control the BC format.
With the binary for now being just the rtsp.

I do think perhaps we should think about how to add other features. Do we want to include more services into the same binary e.g.

neolink rtsp --config=...
neolink talk --config=... --sound_file=... --camera=...

Now might be a good time to think about what we want neolink to be. Just an rtsp bridge or a generic set of tools for the reolink cameras.

[thirtythreeforty]

Yeah, I'd be in favor of multiple sub commands, because as you say there's multiple ways to poke the camera. Sometimes you want to run an rtsp or mqtt or (hypothetical) talk daemon (or one that does any/all of the above). Sometimes you want to single-shot reboot the camera, or change its timestamp. Or whatever.

Still advocating for a single binary because it reduces logistical complexity, although I could perhaps be persuaded to split into a daemon and a CLI tool.

Agree on core. Any comms go through that library.

[QuantumEntangledAndy]

Awesome I'll work towards this end and add some docs too. I will add the rtsp sub command and maybe a reboot subcommand as that should be quite simple and serve as an example for others.