Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Nov 2015 10:06:40 -0800
From:      Garrett Cooper <yaneurabeya@gmail.com>
To:        Andrey Chernov <ache@freebsd.org>
Cc:        Adrian Chadd <adrian.chadd@gmail.com>, Dan Partelly <dan_partelly@rdsor.ro>, freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: libXO-ification - Why - and is it a symptom of deeper issues?
Message-ID:  <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com>
In-Reply-To: <5648C60B.6060205@freebsd.org>
References:  <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <CAJ-Vmokfo_BGWji9TrgQ40oRxqht9-2iEZVon7aQxR_93Ufxyg@mail.gmail.com> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <CAJ-VmoniBAmWTf9MkCCMYhRbPLc=0%2Bz5kRSijXfqX9VZvm8jDg@mail.gmail.com> <5648C60B.6060205@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Nov 15, 2015, at 09:51, Andrey Chernov <ache@freebsd.org> wrote:
>=20
>> On 15.11.2015 20:37, Adrian Chadd wrote:
>>> On 15 November 2015 at 09:10, Dan Partelly <dan_partelly@rdsor.ro> wrote=
:
>>> Meaning, is that simple to push things in head , if somone does the work=
, even with with no proper review of the problem at hand , and the proposed s=
olutions ?
>>=20
>> Nope and yup. The juniper folk had a solution to a problem multiple
>> people had requested work on, and their proposal was by far the
>> furthest along code and use wise.
>>=20
>> It's all fine and good making technical decisions based on drawings
>> and handwaving and philosophizing, but at some point someone has to do
>> the code. Juniper's libxo was the furthest along in implementation and
>> production.
>=20
> It seems it is the only and final argument for libXO existence. I
> remember 2 or 3 discussions against libXO spontaneously happens in the
> FreeBSD lists, all ended with that, approximately: "we already have the
> code and you have just speculations". Alternative and more architecture
> clean ideas, like making standalone template-oriented parser probably
> based on liXO, are never seriously considered, because nobody will code
> it, not for other reasons.

We lack a [dtd/json] spec for tools, so programming for xo'ification doesn't=
 seems like the best idea in the world to me from a end-user sysadmin/develo=
per perspective.

I could just as easily use standard tools like awk, grep, sed, and more adva=
nced languages like perl or Python to parse output, and assuming output does=
n't get a major rewrite, I'd just go with that method that's worked pretty w=
ell for me over the last 10 years of my career..

Cheers,
-NGie=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6EDFB74B-2206-46E7-85F7-8DE05FB6D325>