X-Authentication-Warning:	delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient:	geda-help AT delorie DOT com
Date:	Thu, 3 Sep 2020 23:38:01 +0200 (CEST)
From:	Roland Lutz <rlutz AT hedmen DOT org>
To:	"Roger Traylor (traylor AT engr DOT orst DOT edu) [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com>
Subject:	Re: [geda-help] Linux
In-Reply-To:	<333FD0E9-238C-445F-AEE4-850B0EA19A88@ece.orst.edu>
Message-ID:	<alpine.DEB.2.21.2009032331420.4145@nimbus>
References:	<CAMw9acCtcyZW7HTp0CGHqygGbjXK8_SZiNzn-+Z0cNiuNHL85g AT mail DOT gmail DOT com> <20200829221451 DOT GA2565 AT newvzh DOT lokolhoz> <CAMw9acCbnS9X5Cph_hbkqghGoCTb4Ac+GNT+QRx1wOJ_uoNyUA AT mail DOT gmail DOT com> <CAMw9acCBEy0Q0zMu2+duP_E12po9uoFs9jD7Cafzu_tXiRCHOQ AT mail DOT gmail DOT com>
	<664de6c2-ad96-8298-1b64-ad550acfca64 AT k4gvo DOT com> <CAMw9acAxLN+NU0cbmTfPFHrYyFmvMkAdpyPuaDBzd8S9HaTN7Q AT mail DOT gmail DOT com> <20200901193434 DOT GB19839 AT newvzh DOT lokolhoz> <CAMw9acBo6uMTgS-Sp24aVxq+y8d9XXC+RTHJTJY23rquzm+Fmw AT mail DOT gmail DOT com> <20200902141116 DOT GA2911 AT newvzh DOT lokolhoz>
	<CAMw9acCQV0WTSERpeM=AHj3+p1ACe7Me--4f8xMc000Fs+j7OA AT mail DOT gmail DOT com> <20200902165424 DOT GB2911 AT newvzh DOT lokolhoz> <333FD0E9-238C-445F-AEE4-850B0EA19A88 AT ece DOT orst DOT edu>
User-Agent:	Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version:	1.0
Reply-To:	geda-help AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-help AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Hi Roger, hi all,

in order to give a more complete picture, I'll provide my perspective on 
the matter.

When I joined the project, gEDA/gaf development had more or less stalled. 
There were a few fundamental problems which made improving the situation a 
challenge:

- gEDA/gaf was (and in many aspects still is) a huge monolithic codebase 
which makes it hard to fix one thing without breaking another thing.

- While there is an API to libgeda, it is specific to Scheme (so most of 
gEDA/gaf doesn't actually use it) and exposes many implementation details 
to the user, making it unnecessarily hard to change gEDA/gaf internals 
without breaking user code.

- Many more advanced use cases of gEDA/gaf required knowledge of Scheme, 
which is a significant hurdle to adoption.

Back then, it was almost universally agreed on that the core functionality 
of gEDA/gaf needed to be split out as a library, so it could easily be 
used by gEDA/gaf, scripts, and other applications alike.  See for example 
this brain-storming from 13 years ago:

http://wiki.geda-project.org/libgeda3

So I set out to do exactly this, while trying to avoid the pitfalls that 
had led to this situation in the first place.

http://www.delorie.com/archives/browse.cgi?p=geda-user/2015/02/06/14:35:33

This approach, among other things, allows for much cleaner code in both 
gEDA/gaf and scripts.  More importantly, it also makes it possible to 
access common data structures--which would e.g. allow to run a script from 
inside gschem, operating on the currently opened file.

Now it turns out I underestimated the Scheme lobby.  Vladimir flat-out 
refused to work with my code, and after some heated discussions, he 
decided to rather leave gEDA/gaf and do his own thing than accept that 
gEDA/gaf would in the long term migrate away from Scheme.

I believe this is a sad thing, and that splitting the efforts is overall 
harmful for the project; but I agree that our approaches are incompatible 
and that going different ways is probably the best thing to do.

Roland

- Raw text -