X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Sun, 13 Sep 2015 18:44:36 -0400
Message-Id: <201509132244.t8DMia3n005526@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <20150913231213.0a829971@jive.levalinux.org>
	(geda-user AT delorie DOT com)
Subject: Re: [geda-user] Apollon
References: <20150913140631 DOT 1da1b78d AT jive DOT levalinux DOT org>
	<CAC4O8c_WSck-z2V+iQRZY5HJf2WOu6=ozRpmo6zFGUf5r6DjMA AT mail DOT gmail DOT com>
	<20150913190132 DOT 1926c471 AT jive DOT levalinux DOT org>
	<CAC4O8c-99=qdVrz_-sOLAcr+JGemWf3Gp1NoZzsthG-i8F7vNQ AT mail DOT gmail DOT com>
	<20150913204337 DOT 1e58475a AT jive DOT levalinux DOT org>
	<CAC4O8c_rSibSjCuWv6KaCBTFkjAumCtCub+kpwAi2rEGcOjxFw AT mail DOT gmail DOT com> <20150913231213 DOT 0a829971 AT jive DOT levalinux DOT org>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> > 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.