Mail Archives: geda-user/2016/01/06/08:30:57
Levente:
...
> When selecting a file format I would not have such constraints like "it
> should be pretty for a human eye". CAD data is so complex, that one can
> (and I believe should not) parse them with naked eye. For a computer,
> binary is much more efficient.
If we really are going the "complex cad data" route, I'd head Peter
Cliftons advice to use step. And if I'd start programming with that I
wouldn't concider the price of the step-cd be of any consern.
> So I still prefer the SQLite database, as that library is optimized for our
> purpose. Yes, I prefer to have a library, that parses our files, and gives
> us the possibility to use, or modify the data. I prefer this way because we
> have approx. 50 different implementation of pcb/gschem file parser. There
> is one in pcb/gaf, and all the other power users wrote their own. It would
> be much better to write the parser once, and other could use that. If file
> format changes, you have to just change one code, and not 50+.
I agree that it would be wery nice to have a lib for sch/pcb file
(regardless whatever format they have) parsing+extra with bindings to
mult. languages. But as you said we already have one (+49 others),
I don't which one is the best one, do you know ?
Can we take that one and improve upon ?
> If we use a standard file format (SQL, YAML, JSON), the parsing library
> could be very thin. The independent parsing code is already written. Only
> the application (gEDA) specific code has to be written. Remember, all of us
> has very limited time to contribute code to gEDA nowadays.
So your stance in the end, is that it is the doers who decide,
irrelevant if the lib is thin or thick ?
And the first step would nevertheless be to be able to parse the
current formats, at least for backward compatibility.
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
- Raw text -