On Mon, Nov 27, 2017 at 3:57 PM, Andrew Price <anprice@xxxxxxxxxx> wrote: > Hi, > > 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. However, if gfs2-utils does not need anything more, there is no need to use a complex solution for this moment. 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, 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. Cheers, Jan > strings for extended options so it shouldn't take much work to repurpose > that. That said, I don't think passing options to tools in this way holds > much value over specifying them in argv. > > Willing to budge for consensus, though. >
