X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Mailer: exmh version 2.8.0 04/21/2012 (debian 1:2.8.0~rc1-2) with nmh-1.5
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
From: karl AT aspodata DOT se
To: geda-user AT delorie DOT com
Subject: Universial data model (was Re: [geda-user] Pin length stretch for schematics symbols useful?)
In-reply-to: <20140304202748.27343.qmail@stuge.se>
References: <1391043267 DOT 2058 DOT 19 DOT camel AT AMD64X2 DOT fritz DOT box> <20140303174655 DOT A167B807ABF3 AT turkos DOT aspodata DOT se> <1393874264 DOT 2120 DOT 51 DOT camel AT AMD64X2 DOT fritz DOT box> <20140304124149 DOT 2ECEF807ABF4 AT turkos DOT aspodata DOT se> <20140304202748 DOT 27343 DOT qmail AT stuge DOT se>
Comments: In-reply-to Peter Stuge <peter AT stuge DOT se>
   message dated "Tue, 04 Mar 2014 21:27:48 +0100."
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Message-Id: <20140305121305.735C4807ABF4@turkos.aspodata.se>
Date: Wed,  5 Mar 2014 13:13:03 +0100 (CET)
X-Virus-Scanned: ClamAV using ClamSMTP
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

Peter Stuge:
> karl AT aspodata DOT se wrote:
> > Think of, just one symbol.
> 
> Creating a universal data model for parts is indeed key for free and
> open source EDA software to have any kind of significant impact in
> the world.

I was mostly thinking about the graphics, but yes, one can extend it to
other dimensions also.

...
> It is also not a task that neccessarily has anything to do with
> existing EDA suites, beyond that the data model must of course not
> repeat any mistakes that have already been made in existing programs.

I don't have much experiences with eda suites, is there a list 
somewhere of the mistakes, or can we make such a list, so we can avoid 
them ?

> The data model exists between EDA suites, fabs and part vendors.
> (User requirements flow from EDA suit and/or fab.)
>
> The model must encompass every real-world characteristic of parts
> which EDA suites and fabs care about today, and ideally also be
> future-proof enough that the same model can be extended, as EDA
> suites and fabs learn to make use of even more part characteristics
> in the future.
> 
> The project as I see it would have as deliverables a specification
> document and a portable C library implementing the specification.
> 
> I'd suggest a permissive license such as MIT for the implementation,
> so that the door is open for closed source EDA suites and fab tools
> to use the library later on, thus giving the project a chance to
> eliminate the ridiculous exclusivity of parts within single EDA suite
> vendors, and allow for somehow sensible integration across the full
> design and production cycle.

I'd be fine with lgpl.

> Anyone else interested in this?

Is this the thin/thick symbol discussion again ?

Previous such discussions didn't bear fruit, how can we make it
happen this time ?

What are people using now, what common threads of thoughts can we
find in different solutions ?

And yes, the thin thing must be supported.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57