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
Content-Type: text/plain; charset=UTF-8
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
Precedence: bulk

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.