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

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

- Raw text -