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

[Julian Elischer]

On 11/16/15 1:51 AM, Andrey Chernov 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.
I believe that was my suggestion.. (thus automatically gaining 
negative votes from certain scandinavian countries).
I still think it is better because it would give a framework for 
adding templates for third party applications for which
libXO will NEVER be an option. LibXO could be the backend for 
outputing the data.

>