X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=n9J4KyODlGhhB4q6SCEhbUZv62AAHBr4MQV4PPCFXQM=; b=vxcxf0NNBydSZz/XnZSDWOdtkk92Vdsq341BMaDvIOMC4k28riiRDwUWfAd3e4x7fe p6xuG4vWQB4KHbyhHbSy1Pk7iClgfsHHlDXijuGNt0yhgBgt3XeOJS7jq6Lx13KPs3Dz jqlgqbGJFs79tlYchOj1BnEdcze5EMl+r2I8OwxSfi76FcHXc3yLd78ZmF0+j+qoxwlY /9zfRSEAycQxRMgIpD4a+bjY2sV/bi8EwbLQXX2Y/Rk9tFJoVCpGW0so8cJnU2m0+vrV Ld8uiZ1Npqh+u+x9q0ebzS8f4SUJWHjSfP2sqD1UCmIa+HjinrM4n+R+vG47XyI6NuZi cjng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=n9J4KyODlGhhB4q6SCEhbUZv62AAHBr4MQV4PPCFXQM=; b=QHeSZP88WQSXVBS05Vc3wJL4HWwbEp/+PFO1Is2Pjy5N0M5pUU8yBAN3QgAO1DGpcN IXT29Kn1yb5S6n2CTDIto0iFxUNHuc3LdBkqgahpvCiNNzgu6++WyRZnxD17xwf/zuTl 2u6Y41ZbCB/kDMTailpuOQZvEOTiNZSDWVc2sGOZ2gGu89tIjlIHugHJG3QHmAarNgt1 0/l++r07muSDh6QHQ+mkt5ttfzHABIaPZj2MurMPlBz2NrL3tlFm2VOYMJjuJ2rmvd8U wDV+cXq6opxCw0RpfOZwpXjvteo2HduIu+8e20mnLqOFTCim2f1h9Xwxd2+gG1s9K6ey Kutw== X-Gm-Message-State: AD7BkJKzfIBLqpBI2bI7x/SCJUZL7LTW8hs2jZahc2q5BuyaajI3FI9TwLun18IHQ2Yy/Q== X-Received: by 10.28.133.14 with SMTP id h14mr6460002wmd.100.1459087029567; Sun, 27 Mar 2016 06:57:09 -0700 (PDT) Date: Sun, 27 Mar 2016 15:56:57 +0200 From: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] [pcb-rnd] footprint lib database (sql, sqlite, etc.) becomes real? Message-Id: <20160327155657.59d36feced3f226d24fea5ad@gmail.com> In-Reply-To: References: X-Mailer: Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 > I'm not absolutely clear what you have in mind here, but far more > useful than an interface to a local sql would be some graceful way to > interface to these: > > https://www.snapeda.com > http://madparts.org/ Or simply just support different file formats: it may be other formats or older then fileformat is changed. Integrated circuits usually come in different package sizes for a particular footprint type. There are some generator scripts available but it would probably be good to collect them within source tree just so people can find them. > > So far as I'm aware these are the closest things to an effort to > develop open parts libraries and creation. > > Britton > > On Sat, Mar 26, 2016 at 7:11 AM, wrote: > > Hi all, > > > > as part of the [mods] patches, I am moving a lot of core code to plugins. > > I'm currently finishing moving the footprint list/search/load code. > > > > This makes it feasible to write footprint plugins that don't take footprints > > from the file system, but from sql, or other databases, or the web, or > > wherever. > > > > Plugins can be substituted, different implementations don't interfere at > > all, so there's no "either filesystem or sql" decision forced onto the > > user. As a core plugin, it doesn't bit-rot either. > > > > This feature had been discussed many times in great lengths on the list. Now > > we have the chance to make it real, to convert endless/fruiteless discussion > > into actual code. > > > > Does anyone feel like developing a database (e.g. sql, sqlite, bdb) > > footprint lib plugin? > > > > To estimate complexity: > > > > - the file system (ex-newlib) backend, including pcb-rnd extras (parametric > > footprints) is about 500 lines of code; I expect it to stay under 800 lines. > > I expect a simple db backend to be about the same in length. > > > > - the API currently has 3 entry points; it will grow slightly, but I expect > > there would be no more than 5..8 calls to be implemented. > > > > - the API is very young and no much code depends on it, I am willing to > > make reasonable changes to it to suit a new plugin. > > > > I'd say the setup cost, API/glue part shouldn't be more than two hours; > > depending how complicated the database part is chosen to be, the whole thing > > should take something between 1..3 days. > > > > Regards, > > > > Igor2