Hacker News Reader

Comment by silvestrov | Hacker News Reader

If I was to reimplement it, I would not let any app read the DB directly.

Instead I would make an HTTP like interface where you talk to a service that provides the get/set functionality and which always use a text format like an extended JSON with native support for date, int32, etc.

This also enabled much easier and better backwards compability as you can specify app-version in the requests, so a version 5 server can respond in version 4 format.

With a service it doesn't matter if things are stored as a single sqlite DB or as multiple files.

View on HN

You can do everything you describe with a regular function call. Introducing an unnecessary service for something as trivial as config management is even worse than the broken Registry status quo.

In theory all we need is a libconfig with a standardized interface and distro specific implementations.

There would be two use cases, storing hierarchical/tree like data aka JSON, YAML, etc and arbitrary graph like data with complex references.

The same could be done with the shell. libcli would be called to parse the command line arguments and your program will have an entry point that receives the parsed data.

libcli could also be used to produce structured program outputs which then can be fed into applications, possibly skipping the serialisation deserialization steps.

Since libcli will have a standard interface each distro can choose their own CLI format or whether they output their data as JSON or CBOR.

In both cases the benefit is that the choice of the data storage mechanism has been decoupled from the application.

Augeas does this already: https://github.com/hercules-team/augeas

Is this sarcastic?

I mean, the versioning part sounds good, but JSON like request?

I do believe people don't know what inefficient/efficient a system can be depending on the data format they are using.

That's sort of already the case. Normal apps aren't really supposed to read it, the kernel hides the implementation, and get/set/etc is all system calls.

It's tooling created for security and forensics that tries to manually read it.

https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis...

Registry settings already have ACL items applied. You can see this behavior if you log in as a non admin user then try to view another users registry settings.

https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis... The thing is pretty free form with a choice of some very basic data types dword/qword and strings ascii/unicode/lists of strings.

Adding a wrapper around the existing call to go towards a json schema registry could be a helpful thing.

All the aspects you mention can be realized by a programmatic OS API as well. No need to sandwich a network layer and a weakly-typed data format (JSON) in between.

I assume the service will run in a docker container too??

The article's complaints about the format being undocumented are ill-founded, because Microsoft repeatedly tells developers not to read the registry directly, and call the exquisitely documented functions instead. The applications that didn't listen to Microsoft and depended on particular features are most of why it hasn't updated to modern standards in the first place.

How's that supposed to work if you're modifying it in an offline image from a Linux host?

With DISM.

DISM is a proprietary Windows tool, so no use at all for modifying an offline image from a Linux host.

I'm sure it runs under Wine. But knowing that that's how you service the image means you have no reason to be using a Linux host to do it.

the registry needs to be read by device drivers including the drivers for tcp and nics, including during very early boot. this would make HTTP a challenge. Also implementing a json parser in the kernel sounds like a bad idea

Reply on news.ycombinator.com