X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Message-ID:	<20140709082514.10483.qmail@stuge.se>
Date:	Wed, 9 Jul 2014 10:25:14 +0200
From:	Peter Stuge <peter AT stuge DOT se>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] pour clearing around pads
Mail-Followup-To:	geda-user AT delorie DOT com
References:	<tdei7xok2jel0ik0d6j1r048 DOT 1404843436262 AT email DOT android DOT com> <53BCDC7E DOT 5040001 AT sonic DOT net>
MIME-Version:	1.0
In-Reply-To:	<53BCDC7E.5040001@sonic.net>
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

Dave Curtis wrote:
> So the point of the above paragraph is, yes, I can suggest some extensions, 
> and now would be a good time to capture that since I am trying to wrap my 
> head around the issues right now.  What I can do:
>
> 1. write up some straw-man spec extensions
> 2. update the "footprint creation for.." document with what ever settles 
> out of that.

Thanks for that!

I strongly agree with a unified data model effort.

But - in order for a database to become meaningful it needs to
explicitly support all "desired variations" already in use, and
probably have hooks to add new ones. Some examples of such desired
variations are:

* extending smd pads away from packages for easier hand soldering
* different paste aperture margins depending on stencil process
* bumping unplated drill diameters when fab only supports plated holes
* chip vendors having slightly different package specs for same package

and definitely many more.

Each variation needs to be a single check-box in a user interface,
which can be switched on and off at any time. Most variations have
parameters, which also need to be represented in the data model, as
variation profiles, so that users simply select the right fab profile
and done.

Crowdsourcing the data is important, ideally allowing publication
from within the app itself, and certainly allowing
installation/updating of data from within the app itself. Think
Firefox extensions. A similar process needs to be supported for
adding a new fab profile, which might contain parameters for several
standardized desired variations, and possibly add fab-specific
variations.

Developing and maintaining such a data model is no simple nor small
task. I'll help work on it.


> What I can not do:
>
> Investigate the feasibility of implementing the extensions.  I simply
> don't know the code well enough.

I don't think any existing code fits a unified database and I think
it's OK to create an ambitious project to change that in the medium
to long term. The data model is the first step though, code comes
(much?) later.


Of course this is all no solution for the immediate term, but an
investment in open source tooling that might only really pay off
in a decade or three.


//Peter

- Raw text -