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:mail-followup-to:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=PGuLNmmRj2ws2ABn+7YC+ZoKUHHbqvtWul+rQhy6D6c=;
	b=g7rXMXVanNZZ2KuV59qZWFMG0q9dJDsBXhhgbN1+lBnBk3GuAZCh/ot1/vobTGqRru
	Sts827yiT0EKv3/GxbxzoXR4K9wmfTusz48jaSCyDMxYTAmB0GF72MVdqeqtKfGT2sIJ
	d5jc2Rs6e+2nkziftODYZphbD0fExBET96zGEF6ceZDntC2ugdH3sM0tHakwY8cDT4Ux
	6jwMakjPgKEkQYlj9fiw8mTbZIszAXifTASrn36T0qvzQX4Kf7yIRGH1bb4SwpRxCTO2
	e7jeiH/N271wg56bxCD4O3qEsGLeMh2xaUoBRPrZc9sYO6D4MZeO+/5PL0a2j+uIzvKi
	OCKA==
X-Received:	by 10.112.151.178 with SMTP id ur18mr3303846lbb.59.1436263995674;
	Tue, 07 Jul 2015 03:13:15 -0700 (PDT)
Date:	Tue, 7 Jul 2015 13:13:12 +0300
From:	"Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] libgeda3
Message-ID:	<20150707101312.GB15599@localhost.localdomain>
Mail-Followup-To:	geda-user AT delorie DOT com
References:	<CAM2RGhSkHSm8h571=3GePQUm-HAnxeb7-HCF=p2a+QUzP6rNkA AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 11 DOT 1507041329400 DOT 8210 AT nimbus>
MIME-Version:	1.0
In-Reply-To:	<alpine.DEB.2.11.1507041329400.8210@nimbus>
User-Agent:	Mutt/1.5.23 (2014-03-12)
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

On Sat, Jul 04, 2015 at 02:19:32PM +0200, Roland Lutz wrote:
...
> The main difference between the libgeda3 and Xorn philosophies is that I'm
> not trying to provide an API but a Python ecosystem in which different parts
> of the code (e.g. upstream Xorn/gEDA and user code) interact natively.  All
> code is "part of" the ecosystem in some way, regardless of whether the user
> has invoked it using one of the existing command-line programs or it has
> been included by another application.
...
> I think Xorn is the way to go for future gEDA development.  Once I've
> cleaned up the pythonized version of gnetlist, it could be included in
> upstream gEDA, leaving gschem as the primary remaining user of libgeda.
> Porting the smaller tools to Xorn shouldn't be a problem.  Then libgeda,
> with all its gschem-specific functionality, could be made a part of gschem
> again.  By having it use the Xorn primitives, code duplication could be
> reduced, and gschem could be integrated with the rest of gEDA on a
> schematic-manipulation basis.

My point of view here is it would be better to forbear from
high-level language wars. Some people like Scheme, others prefer
Lua, Perl, Python and so on.

We already use glib/gobject libraries within libgeda. Why not
just use the possibilities they have. There are already bindings
for several languages, e.g. for Python [1] and Guile [2]. The more
complete list is at [3]. 

I probably don't quite understand your ecosystem approach since
I've never had enough time to look through your code. However I
realize that geda-gaf programs could be more tight bound if we'll
use the extension approach vs embedding [4] (it is also
interesting, what the author tells about using of multiple
interpreters for one application). Anyway, users are already able
to combine various programs together using the 'system' call.

I think, some reasons why some developers prefer using API's
instead of making program objects available to the user are
described at [5].

[1] https://wiki.gnome.org/action/show/Projects/PyGObject
[2] https://www.gnu.org/software/guile-gnome/docs/glib/html/
[3] https://en.wikipedia.org/wiki/List_of_language_bindings_for_GTK%2B
[4] http://twistedmatrix.com/users/glyph/rant/extendit.html
[5] http://www.gnu.org/software/libtool/manual/html_node/Library-tips.html

Cheers,
  Vladimir

- Raw text -