X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Date:	Mon, 13 Feb 2017 08:38:40 +0100 (CET)
X-X-Sender:	igor2 AT igor2priv
To:	geda-user AT delorie DOT com
X-Debug:	to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From:	gedau AT igor2 DOT repo DOT hu
Subject:	[geda-user] RFC: edacore - should we reboot it? the EDA ecosystem
Message-ID:	<alpine.DEB.2.00.1702130818300.7286@igor2priv>
User-Agent:	Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version:	1.0
Reply-To:	geda-user AT delorie DOT com

Hi all,

There are things going on in pcb-rnd; emphasis slightly shifting. E.g. we 
are much less coupled to gschem and we are less dependant on gEDA/PCB file 
formats than we used to be. We can now communicate with more and more 
random EDA tools. We also have some web related plans with some code 
already implemented behind the idea.

4..5 days ago I realized these otherwise independent efforts will 
eventually all connect up and will yield something that's in 
considerable overlap with some of the edacore concepts - even if the 
implementation and the path we are getting there differs from edacore's.

I've written 3 writeups on the topic. I am interested in your opinion 
especially on the higher level aspects. I know they are long, but please 
DO READ THEM ALL, from top to bottom, before commenting in this thread. 
Please try to describe your ideas in relation to what's written in these 
docs instead of just throwing in random aspects. Please state if you are 
also willing to contribute, and if so, in what way, to what extent.

Let's also try to skip the usual programming language, version control, 
etc. flames out of it this time. Please also note that at this stage, we 
are talking about real high level concepts - tiny technical details on the 
bottom are not really interesting unless they are examples of interference 
on the high level.

1. the EDA ecosystem idea:

http://repo.hu/projects/pcb-rnd/devlog/20170212_ecosys.html

This is already happening in pcb-rnd. In a sense it has a subtle 
overlap with edacore, potentially implementing a similar service and 
mechanism without depending on anything common (no common file formats or 
libs)

2. what's the minimum we'd need to do for a working "edacore" setup:

http://repo.hu/projects/pcb-rnd/devlog/20170213_edacore1.html

These are just ideas, not even real plans. I honestly would like to see 
developer and user opinions on these. I believe if we go for the common 
minimum, we may gain better acceptance and have more chance that the 
project gets anywhere.

3. something that I think was integral part of the original edacore idea 
but I think should be a separate package to keep things simpler:

http://repo.hu/projects/pcb-rnd/devlog/20170213_edacore2.html

Again, just ideas, not even real plans. I'm especially interested in 
user opinions on this.

Regards,

Igor2

- Raw text -