Hello, Am Donnerstag, 23. März 2017, 00:27:55 CEST schrieb Seth Arnold: > On Wed, Mar 22, 2017 at 01:24:04PM -0500, Goldwyn Rodrigues wrote: > > From: Goldwyn Rodrigues <rgold...@suse.com> > > > > This adds JSON support for tools in order to be able to talk to > > other utilities such as Yast. > > > > The json is one per line, in order to differentiate between multiple > > records. This is based on work presented by Christian Boltz some > > time > > back. > > Hi Goldwyn, thanks for the update. It looks good to me with only the > tineist of concerns -- first, this "one per line" idea. It feels like > it'd be more resilient if instead of using multiple json documents, > one per line, it'd be one json document with an array if an array is > needed, and make the whitespace as unimportant as possible.
Each line needs to be handled by itsself, so I don't see a real problem
here.
In many cases, only a single line (a prompt asking to allow something)
will be printed.
If there are multiple lines (let's say, first a message to display and
then a prompt), that message typically is a response to the previous
step.
Maybe this is not technically perfect, but it makes things much easier
on both ends of the pipe.
Just as an example - printing a message ("$foo added to profile $bar")
would need to be "buffered" because typically there's a prompt
afterwards, and printing a prompt would need to make sure also to print
that message. And that's assuming that there's always a prompt after
printing a message, which isn't always true - saving all modified profiles
will print a message, but aa-logprof exits afterwards.
As long as YaST knows that it has to read another line after displaying
a message, I'm fine with having one json document per line. (Maybe we
should add a "response_expected": True/False to all the json output?)
> Of course I expect yast to be the only consumer of this interface for
> a while, so if yast expects multiple json docs, then that's just what
> it ought to be. But if this interface is more flexible then I'd
> suspect that passing a single json document between processes would
> be more reliable.
I seriously hope we'll see an unittest as second customer ;-)
> > --- a/utils/aa-genprof
> > +++ b/utils/aa-genprof
> > +parser.add_argument('-j', '--json', action="store_true",
> > help=_('provide output in json format'))>
> > --- a/utils/aa-logprof
> > +++ b/utils/aa-logprof
> > +parser.add_argument('-j', '--json', action='store_true',
> > help=_('provide the output in json format'))>
> The other thing is that these two --help outputs are different; one is
> "the output" and the other is "output'. I think having them identical
> would make the tools feel more polished. (Every bit helps.)
Agreed, using the same text in both makes it more polished and also
saves some translation work.
Regards,
Christian Boltz
--
Wenn Du Dich weiter doof stellst, dann:
Warning: loading builtin philipp-cool-down.dll. Couldn't be loaded!
Expect trouble!!! [Philipp Zacharias in suse-linux]
signature.asc
Description: This is a digitally signed message part.
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
