On 27/11/17 15:38, Jan Tulak wrote:
On Mon, Nov 27, 2017 at 3:57 PM, Andrew Price <anprice@xxxxxxxxxx> wrote:
On 30/06/17 09:17, Jan Tulak wrote:
AKA filesystem API
Hi guys
Currently, filesystem tools are not made with automation in mind. So
any tool that wants to interact with filesystems (be it for
automation, or to provide a more user-friendly interface) has to
screen scrape everything and cope with changing outputs.
I think it is the time to focus some thoughts on how to make the fs
tools easier to be used by scripts and other tools.
What's the status of this? I'd like to make sure gfs2-utils is geared up for
it and catered for, whatever solution is chosen.
I decided to go the way of using wrapper at first - that solves some
of the use cases I'm concerned sooner. And if there are enough users
of this wrapper, then in a time I can look at the integration again.
Perhaps this ship has already sailed, but, I think a json dependency may be
a little too heavy, and perhaps a simpler stream of key-value lists that can
be generated with fprintf() would suffice? For accepting options, we already
have code to parse that sort of thing as we handle "foo=bar,baz=42" style
That's not enough once you have any hierarchy in your data, i.e.
multiple volumes in a group, and each has a name or path... Hence, I
strived for an advanced format, like JSON.
A nested format is not necessarily required to describe a nested
structure. It does take away the need for a "parent" field in each
record but I'm not convinced that is a sufficent trade-off for adding a
json lib dependency.
However, if gfs2-utils does
not need anything more, there is no need to use a complex solution for
this moment.
I think the only hierarchical support we might want is for progress
reporting to be split into stages and sub-stages.
What makes it easy to add a common format, later on, is not having
prints all through the program together with a heap of exit() calls,
I'm not sure I understand this point...
and rather, if there is some structure containing the state from which
the output is created at one point no matter what. Of course, that can
be difficult to achieve if you want to print some progress or if the
program would require deeper changes... which is why I let it be for
now until I can show that there really is a sufficient interest from
the users of a wrapper, and the effort is better justified.
Okay, thanks for the update. In case it helps in future, I'm willing to
experiment with a (test?) tool that works with the gfs2-utils in a
development branch.
Andy
