On Tue, Dec 22, 2015 at 8:23 PM, John Doty <jpd AT noqsi DOT com> w= rote:

On Dec 22, 2015, at 9:31 PM, Evan Foss (evanfoss AT gmail DOT com) [via ge= da-user AT delorie DOT com] <geda-= user AT delorie DOT com> wrote:

> On Tue, Dec 22, 2015 at 11:47 PM, John Doty <jpd AT noqsi DOT com> wrote:
>>
>> On Dec 22, 2015, at 4:22 PM, Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com] <ge= da-user AT delorie DOT com> wrote:
>>
>>> John Doty wrote:
>>>>> Bonus points for PCB using the core-library too, so it= can "give up"
>>>>> its one preferred on-disk netlist format, and read any= useful ones we
>>>>> care to implement a reader for in the core EDA library= .
>>>>
>>>> I=E2=80=99m quite skeptical of a core library. An agreed-u= pon external data
>>>> representation is handy, but tool writers will want their = own
>>>> internal representations in their own languages for their = own problems.
>>>
>>> The purpose of a core library is to take care of the lower-lev= el
>>> things required to deal with the external data representation.=
>>
>> I=E2=80=99d prefer to make the external representation transparent= .
>>
>>>
>>> It is key for a core library to make all available data easily= usable
>>> for tool writers, not to enforce a particular internal represe= ntation.
>>
>> But of course, it will use a particular representation. A core lib= rary for C++ isn=E2=80=99t going to be useful to an AWK programmer.
>>
>> One thing that=E2=80=99s nice about our .sch format is that it is = easy to read and write from pretty much any language. There=E2=80=99s no ne= ed for any extra layer.
>
> Yes but with an extra layer more people can play with files made in > PCB.

I was speaking of geda-gaf.

> Why force them to write and maintain a whole second library to
> handle our file format? Look at the number of utilities that people > have written to create footprints and things via their own file
> parsing code. That is a lot of duplicated effort that will be broken > when we revise the format.

But you need *many* parsers to serve our modern Babel of programming= languages. If you insist that people go through an API that isn=E2=80=99t = in their favorite language that=E2=80=99s a much bigger barrier than the la= ck of a common parser. Even if the API is in the right language, its data s= tructures may need translation. Parsing is not usually hard. Dealing with a= n API ill suited to your problem is often harder.

Agreed.=C2=A0 I like YAML for this reason.=C2=A0 You = get a parser in every language for free, without any other library material= required.

=C2=A0