On Jan 2, 2016, at 9:27 PM, Britton = Kerin (britton DOT kerin AT gmail DOT com) = [via geda-user AT delorie DOT com] = <geda-user AT delorie DOT com>= wrote:

On Sat, Jan 2, 2016 at 6:07 PM, John Doty <jpd AT noqsi DOT com> wrote:

On Jan 2, 2016, at 7:47 PM, = Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> = wrote:

On Sat, Jan 2, 2016 = at 4:38 PM, John Doty <jpd AT noqsi DOT com> wrote:

On Jan 2, 2016, at = 6:07 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> = wrote:

Personally I find formats like this:

= device=3DRESISTOR
T 44400 49300 5 10 1 1 90 0 = 1

substantially less readable than ones with field names, but = they are indeed easy to = parse.

Personally, I rarely edit = these things manually except for the text fields, which are not = difficult to find. The fact that they=92re easy to parse is handy for = automation.

The pcb format is quite a bit more elaborate and the = savings from not rolling your own parser are more = significant.

I think you're criteria for what should go in libgeda are = spot-on btw. Nor do I have any problem with a C interface calling = python or gschem or for that matter C++. I do think providing a = clean C interface to libgeda gets by far the best return on investment, = since it's so widely known and with a little care wrappers can then be = provided almost automatically for a wide variety of languages (via SWIG = or some other similar mechanism -- or maybe Xorn facilitates this, I'm a = little unclear).

I don=92t find = deconstructing C data structures particularly easier than parsing the = format above. Just another layer I have to penetrate to get to the data. = I do significant processing with simple things like sed, which don=92t = handle binary data.

Wrappers CAN be provided, = but will they? FFI programming is not the easiest thing. I hear = complaints about the need for developers to maintain code. It = seems to me that one way to address these concerns is to avoid and = eliminate unnecessary = code.

Good question. = It's a great result if you get it but a lot more work than using a = serialization library, which is why the latter approach seems to me like = a useful step in the right = direction.
Serialization library? = Why do you want a extra, unnecessary, opaque interface? What, exactly, = are you trying to = accomplish?

Two = things:

= 1. A human- and partial-parser-script-readable = format

We have = that, I think. But you left out the most important virtue: = *simple*.