|
|
|
|
|
|
by defanor
968 days ago
|
|
|
The repository's README.md links to <https://docs.streamdal.com/sdks>, which is not there. Those SDKs are simply libraries though, aren't they? "SDK" often stands for more than that (e.g., development tools, bits of code not properly packaged), and may be appalling if you don't want to wrap a project around such an SDK, as opposed to merely incorporating a library. But then I wonder why it has to be a library at all, limited to just 3 languages: why not to implement a more unixy interface, perhaps with named pipes? And/or a library with C API (so that it can be called from any common language), providing file descriptors to write into. With the former approach, basic named pipes or files and actual tail -f can be used, too. |
|
|
re: libs vs sdk - we named it that in anticipation of exactly having to do some funky stuff. As it stands, we are already doing grpc, Protobuf, wasm and having it all interop across all languages is not easy - so having to introduce some sort of a “helper” binding/lib is not at all unlikely.
Besides that, the “tail” part is really a small part of the functionality - the overall idea is that the sdk/lib has access to most/all I/O of the app and is able to interact with the payload that the caller provides before it is sent on its way.
Traditional pipes aren’t really in the equation.
We went with calling it “tail” because it’s easier to explain instead of “it’s a lib that an app owner can wrap their i/o calls with to enable calling dynamic wasm”… and that’s still not the whole thing haha
Last, here’s a diagram depicting the flow: https://docs.streamdal.com/_astro/StreamdalSdk.cd7c8d45.png