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 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: <53BCDC7E DOT 5040001 AT sonic DOT net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Precedence: bulk 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