Mail Archives: geda-user/2015/09/13/18:44:47
> > But if DJ and others support the idea of just starting off with a
> > new format,
I support the idea of creating a new file format as part of an
expansion of pcb's internal data model, as the old format has been
pushed to its limits.
I support the idea of making a pcb parser available to external
scripts, although I'd rather avoid writing a new parser just for that
purpose if pcb's existing parser can be reused (which has become
easier with recent work).
I don't support the idea of replacing PCBs parser "just because"
you don't like the file format.
I don't support the idea of designing a new PCB file format with lots
of new features if nobody is going to add support for those features,
or if it's unreasonable to expect anyone to add support for them.
> > xml is the most painful of the plain-text options.
>
> Yes.
And yet, everyone begged for it back when... :-P
> but I think the heavy lifting is the data structure redesign in pcb.
I agree. The hardest problem is adopting a new data *meaning* within
pcb itself. Do we change what's in a footprint? Do we support
sub-layouts within sub-layouts? Do we share padstacks and footprints,
and if so, how do we make exceptions? What about multiple fonts?
These are all examples of things people have wanted in the past that
need a new data model. IMHO we have to decide these *first*, and let
the file format follow, even if we implement them later.
For example, if we decide that footprints should allow additional text
(besides the one refdes/value/description field), we can allow for
that in a new file format, but ignore the extra capabilities for now
until PCB knows how to deal with the new data.
Another example: blind/buried vias. Easy to add a field for
top/bottom layer for via. Much harder to update the autorouter to
know how to use them. This would have to defer allowing in the file
until pcb knew what to do with them.
- Raw text -