delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2013/09/11/03:15:34

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: Wed, 11 Sep 2013 08:14:42 +0100
Lines: 72
Message-ID: <87ioy7vnh9.fsf@harrington.peter-b.co.uk>
References: <87ob83dodl DOT fsf AT harrington DOT peter-b DOT co DOT uk>
<87sixdi6rc DOT fsf AT harrington DOT peter-b DOT co DOT uk>
<CAMvDHVAwWJDFpEuK5GhDMuYVoRxee7G82rT7ZmuvL7UBSJvmEQ AT mail DOT gmail 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:nVryBANC3HOxWo6oawWlF0ZGAeY=
Reply-To: geda-user AT delorie DOT com

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

Vladimir Zhbanov writes:

> 2013/9/10, Peter TB Brett wrote:
> ...
>> - Several people have mentioned the benefits of a project resource
>>   cache.  I agree with almost all of the points made --- a project
>>   resource cache is a great idea.  Let's have one.  But I'm fed up with
>>   having things in gEDA that work "sort of".  If I'm designing a new
>>   subsystem, I want it to work *properly*.  If we're going to have a
>>   design cache, let's have a design cache that behaves like a cache,
>>   looks like a cache to programs and provides an API that lets you carry
>>   out cache-specific operations.  Let's *not* shoehorn it into the
>>   library system by using special magically-name project libraries.
>
> OK, let's call it resource or design cache. However, some project
> can contain symbols needed only for it, which don't have to get
> into the main user library, for example, some connectors or
> sub-schematic symbols which related now only to that project but
> possibly can be used in others in future.

The intention is to support both project libraries (n.b. plural) *and* a
cache of resources used in the project.  You won't be able to edit
things in the cache -- because it will be a cache -- so if you have
project-specific symbols, they need to go in a proper library.  gschem
should support creating a new symbol based on a cached symbol, though.

> Sometimes a symbol, used firstly as a resource, can transform to
> another symbol suitable for the project or even for the user
> library. I think that is why the term 'project library' is
> used. Therefore, I'd like to know more details on what is the design
> cache and what cache-specific operations should be supported by the
> API.
>
>>   Would it help if I added some info to the wiki page on how I think
>>   that a cache should work?
>
> Yes, please.
>

At this stage I don't know (or care) what the API will look like; that
will come once I have decided how it should work from the user's point
of view.  Writing a pile of code and then realising that a design
decision you made near the beginning means that it won't be able to do
the things you need it to do is a waste of time.

The main query at the moment is to what extent (and how) the cache
should track versions of resources.

I'm in Switzerland with very limited Internet until early next week, so
I won't be able to add anything until then.

                              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)

iEYEARECAAYFAlIwGGIACgkQZ7Gbq7g7vppeLQCfYrPAOkAra+oSg+b+z5ZVAkiQ
Z/IAoJEbYu26xEJj3aB8aDTinldacUZn
=BnUi
-----END PGP SIGNATURE-----
--=-=-=--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019