libXO-ification - Why - and is it a symptom of deeper issues?

[Adrian Chadd]

On 15 November 2015 at 09:51, Andrey Chernov <ache at freebsd.org> wrote:
> On 15.11.2015 20:37, Adrian Chadd wrote:
>> On 15 November 2015 at 09:10, Dan Partelly <dan_partelly at 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 solutions ?
>>
>> 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.
>>
>> 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.
>
> 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.

Right. Technical progress is made when people do some work. You can do
all the planning and designing you want, but computers available today
run on code, not on hopes and dreams. :)

I'd love to see the libxo stuff morph into a split between
Allan/others idea of "libify things" and "stuff that handles output
serialisation". Someone just has to do the design and do the code.

So, who wants to code up the template driven, library-for-access,
library-for-output-serialisation pieces? That's what we can commit. :)



-adrian