On 28.12.2016 04:14, David Holland wrote: > On Wed, Dec 28, 2016 at 02:54:00AM +0000, David Holland wrote: > > I... think the library itself looks pretty gross, > > to wit, it's doing almost exactly the same things as proplib or any of > the proposed proplib replacements, just with a very slightly different > goal. > The libxo library as it's done in FreeBSD is an improvement for my use-case, however it's not ideal. I mean, outputing from system/native tools stream in the standarized format like json/xml/yaml/etc. I want to serialize the state of a running system and to achieve this I need to serialize all system tools from *bin, that are not trivial filesystem accessors (I would treat wc(1) as a program in this group - but if there is a use-case to render such property of a file, why not); and render everything into unified format and with a tool like osquery from Facebook. Performant Endpoint Visibility osquery allows you to easily ask questions about your Linux, Windows, and OS X infrastructure. Whether your goal is intrusion detection, infrastructure reliability, or compliance, osquery gives you the ability to empower and inform a broad set of organizations within your company. -- https://osquery.io/ My goal is to make frontend with Lua (meta)tables and (lib)SQL (reuse sqlite?), while translating it to osquery should be straight-forward. I know a potential user interested to use graphql & json for the same task to introspect system and orchestrate system utilities like debuggers. -- http://waywardmonkeys.org/2016/03/15/graphql-beyond-the-web/ I faced a problem that to achieve this task I would need to reinvent tools like ifconfig(8) or mixerctl(1) and base each conceptual set of tables (like for network interfaces) on the ioctl(2) layer or write a parser of stdout for every tool... and maintain it. Another option would be to go for libxo/libprop or refactor our tools into libraries and wrappers - like libifconfig(3) + ifconfig(8). A library and wrapper could use libprop(3) to communicate one the other, and reusing the library by third party tools would be a matter of linking and adding a thin layer to generate appropriate format from serialized Property List. For users requesting JSON or other format offered by libxo.. just link libifconfig and generate what's wanted. As a research, one step forwards is to get libsystem, and another step is to serialize the full-state of system into single file (e.g. Lua state). It's in contrast to the Linux world, as that it's not about reinventing existing tools and mechanisms (like new run level concepts), absorbing them into single library; but the goal is to add accessors to orchestrate already well defined interfaces with a unified format and with unified tool to introspect the system. The goal of my use-case is to generate GUI plugins for system interfaces, e.g. bozohttpd plugins in Lua or administrator panel in a desktop window manager. As far as I know, the goal of libxo was to reduce the cost & effort of creating similar tools. I'm not convinced about libxo as: - It introduces complexity in *bin utilities, - The same task is achievable with already existing libprop(3), - There is need to redefine stdout/stderr functions that have regular idioms like to replace err(3) with libxo alternative, - I would like to bypass the need for execve(2) (effectively going to uniprogram-like solution), - I don't need wrapper for lib* when I want to use introspection layer, - I have number of use-cases to link programs like (lib)ifconfig(8) with C code, while going to the ioctl(2) level or pipe stream and parsing output (even with xml) is heavy.
Attachment:
signature.asc
Description: OpenPGP digital signature