On 03.03.2015 4:45, Alfred Perlstein wrote: > > >> On Mar 2, 2015, at 5:37 PM, Andrey Chernov <a...@freebsd.org> wrote: >> >>> On 03.03.2015 4:30, Alfred Perlstein wrote: >>> >>> >>>>> On Mar 2, 2015, at 4:22 PM, Andrey Chernov <a...@freebsd.org> wrote: >>>>> >>>>>> On 02.03.2015 22:55, Julian Elischer wrote: >>>>>> On 3/2/15 5:27 AM, Alfred Perlstein wrote: >>>>>> >>>>>> >>>>>>>> On 3/2/15 4:14 AM, Julian Elischer wrote: >>>>>>>> On 3/1/15 10:49 AM, Harrison Grundy wrote: >>>>>>>> Thanks! >>>>>>>> >>>>>>>> That does seem useful, but I'm not sure I see the reasoning behind >>>>>>>> putting into base, over a port or package, since processing XML in base >>>>>>>> is a pain, and it can't serve up JSON or HTML without additional >>>>>>>> utilities anyway. >>>>>>>> >>>>>>>> (If I'm reviving a long-settled thing, let me know and I'll drop it. >>>>>>>> I'm >>>>>>>> trying to understand the use case for this.) >>>>>>> >>>>>>> To me it would almost seem more useful to have a programmable filter >>>>>>> for which you could produce >>>>>>> parse grammars to parse the output of various programs.. >>>>>>> thus >>>>>>> >>>>>>> ifconfig -a | xmlize -g ifconfig | your-favourite-xml-parser >>>>>>> with a set of grammars in /usr/share/xmlize/ >>>>>>> then we could use it for out-of-tree programs as well if we wrote >>>>>>> grammars for them.. >>>>>>> >>>>>>> The sentiment of machine-readable output is nice, but I think it's >>>>>>> slightly off target. >>>>>>> we shouldn't have to change all out utilities, and it isn't going to >>>>>>> help at all with 3rd party apps, >>>>>>> e.g. samba stuff. A generally easy to program output grammar parser >>>>>>> would be truely useful. >>>>>>> and not just for FreeBSD. >>>>>>> >>>>>>> I've been watching with an uncomfortable feeling, but it's taken me a >>>>>>> while to put my >>>>>>> finger on what it was.. >>>>>> Are you sure it's not the hairs on the back of your neck standing up >>>>>> due to NIH? >>>>>> >>>>>> Juniper has been doing this for years and it's very useful for them. >>>>> I'm not saying the ability to generate machine readable output is wrong, >>>>> but that the 'unix way' would be to make a filter for it. It seems that >>>>> the noisy people don't >>>>> agree with me so I will not stand in the way of progress.. >>>> >>>> I agree. Even if someone starts with json and xml only, it will need >>>> some 3rd format soon, and adding any new format have real possibility to >>>> break all already existent (like adding json+xml breaks plain text in >>>> pipes). Moreover, it violates Unix principle 'one tool == one general >>>> function' and lots of other rules like Eric Raymond ones, making each >>>> program looks like systemd. It makes harder to merge changes from other >>>> BSDs too. >>>> Proper way to do this thing is to back out all changes and write >>>> completely separate templates-based parser - xml/json writer. >>> >>> >>> Read the library. It doesn't care what output format it needs. It is up to >>> the translation layer to do it. You could even do a csv format or most any >>> other structured output format without changing the userland utils. >> >> I am happy the library can do it. So please stop to change userland >> utils and back out all libxo changes from them. My concern is userland >> utils, feel free to implement anything you need/want without changing >> them in this ugly way. > > > The responsibility is on you to provide something better, both the > architecture AND code. So if you want it backed out, then write something > better. Otherwise step back and let progress happen. >
As it seems you know a lot about my responsibility and duty, I am very surprised by your broad interests. If you let me to speak for myself a bit, I can tell what I feel. In this particular case my responsibility is just to give good advice at the road fork with one way leads to obvious hell, nothing more. I already express my opinion from the technical point of view and don't want to participate in the flame war, so continue this thread without me, please. -- http://ache.vniz.net/ _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"