X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Injected-Via-Gmane:	http://gmane.org/
To:	geda-user AT delorie DOT com
From:	Peter TB Brett <peter AT peter-b DOT co DOT uk>
Subject:	Re: [geda-user] [RFC] Major changes to symbol/schematic libraries in geda-gaf
Date:	Mon, 09 Sep 2013 06:31:53 +0100
Lines:	66
Message-ID:	<87mwnmblx2.fsf@harrington.peter-b.co.uk>
References:	<87ob83dodl DOT fsf AT harrington DOT peter-b DOT co DOT uk>
	<201309082106 DOT r88L6uGB008410 AT envy DOT delorie DOT com>
	<87ppsjas54 DOT fsf AT harrington DOT peter-b DOT co DOT uk>
	<201309082208 DOT r88M8atf023306 AT envy DOT delorie DOT com>
Mime-Version:	1.0
X-Complaints-To:	usenet AT ger DOT gmane DOT org
X-Gmane-NNTP-Posting-Host:	cpc4-oxfd23-2-0-cust628.4-3.cable.virginmedia.com
User-Agent:	Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock:	sha1:YefEENQePjQ6SrE0GI0mXvUwIzw=
Reply-To:	geda-user AT delorie DOT com

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

DJ Delorie writes:

>> The geda.conf files are in a standard file format for which there are
>> many parsers available
>
> Er, not what I meant.  I mean, a "library" could have symbols,
> footprints, and models in it, and gnetlist/pcb/etc would resolve
> conflicting names by searching the symbols' libraries before other
> libraries.  So if you have two "TO220" symbols in two different
> libraries, you get the one from the "same" library when a symbol
> requests it.
>
> I'm thinking of Kai's library, which is already set up for this.

Okay --- so you want there to be an API method to request a resource X
that's located in the same library as another resource Y.  I can do
this.  Probably the way that it will work is that if the place Y is
found changes, then you'll get notified that X has changed too, and if
the new location of Y doesn't have a corresponding X then X will become
unresolved.  You could then put in application-specific logic to DTRT
and look up a default version of X, I assume.

>> > Also, it would be cool if the library "path" included cloud support,
>> > like http:// and git:// paths.
>>=20
>> It would be cool, but I feel like that might be better implemented via
>> helper daemons that just keep an on-disk library up-to-date.  You
>> wouldn't need any synchronisation with gschem; the library system would
>> monitor the filesystem and DTRT when updates occurred (i.e. prompt the
>> user, probably).
>
> I really don't want something as big as, say, the Digikey database, on
> my hard drive ;-)
>
> But consider being able to search gedasymbols.org live, and
> dynamically pull symbols from it...  :-)
>

It's probably something we could support in the future --- there's
nothing in the proposed user interface/configuration file arrangements
that would prevent it --- but I don't consider it a high priority right
now, especially given that 99% of the use cases could be covered by
running a separate program that populates a directory (even as a gschem
subprocess).  I *will* bear in mind the possibility of adding additional
library providers as I design the API spec though.

                    Peter

=2D-=20
Dr Peter Brett <peter AT peter-b DOT co DOT uk>

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEARECAAYFAlItXUkACgkQZ7Gbq7g7vpr2cwCgg+Z9Q+oNADb+nY3qbJL7wYcg
y6cAn1VlK0sd6O+sqSZKwQQ18fhneifL
=1yvM
-----END PGP SIGNATURE-----
--=-=-=--

- Raw text -