delorie.com/archives/browse.cgi | search |
X-Authentication-Warning: | delorie.com: mail set sender to geda-user-bounces using -f |
X-Recipient: | geda-user AT delorie DOT com |
DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; |
d=gmail.com; s=20120113; | |
h=mime-version:in-reply-to:references:date:message-id:subject:from:to | |
:content-type; | |
bh=nl6EnPbGhmh1JDIoX+Jw+fNGJvgZqbIuYTExNigpzgc=; | |
b=BkotAGEePW4H7rLAmbGwL1X/pgDTAgmpWL9/HK3Ak1Fds4NVsUc9KZqI9a+rpeZMkZ | |
XRAcnz5JeuOt6SWKMOodhP+BTLad+/vjZmZGmFO1dSVBJlcvHUI1LgU33ULOsIYkpSB8 | |
rVrRSjeaSLSYV8qvO5aERUCrFCzNP9Heq5EIPauIE05nuokvttEISG0CEtgk51GBaPdv | |
K4z+6DNvOK9B6NST/al/y+Y5kxokNLcT3gs58WtXe8RWLgdVhn3IHy4RmOkm20OjQ3MB | |
bFwBIN7HlKGdwRTaXfa2ydzweKP7mciRgQai8mwIw063RjPy3hIPtUCECYTN2//Xy+hr | |
M1uQ== | |
MIME-Version: | 1.0 |
X-Received: | by 10.52.103.35 with SMTP id ft3mr22335163vdb.5.1378874520201; |
Tue, 10 Sep 2013 21:42:00 -0700 (PDT) | |
In-Reply-To: | <87sixdi6rc.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> | |
Date: | Wed, 11 Sep 2013 08:42:00 +0400 |
Message-ID: | <CAMvDHVAwWJDFpEuK5GhDMuYVoRxee7G82rT7ZmuvL7UBSJvmEQ@mail.gmail.com> |
Subject: | Re: [geda-user] [RFC] Major changes to symbol/schematic libraries in geda-gaf |
From: | Vladimir Zhbanov <vzhbanov AT gmail DOT com> |
To: | geda-user AT delorie DOT com |
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 |
2013/9/10, Peter TB Brett <peter AT peter-b DOT co DOT uk>: ... > - 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. 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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |