kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

I get paid to brainstorm, so brace yourself.

Continuing with library brainstorming, the following is put on the table
for consideration and eventual evaluation. Brace yourself, this is out
of the box.  Open up your mind before proceeding.

Remember the HTML editors which let you view HTML source and the
resultant GUI presentation at the same time?  One panel has the html
source, another shows you its effects.  The following concepts use that
UI paradigm.  Use the source Luke, use the source.


A library is not a library file:
-------------------------------

The concept of a *library file* is gone.  There are none.  The concept
of a library can still exist but it is a RAM resident concept.  Each
component that we traditionally think of residing in a *library file* is
actually in its own file on disk in a directory (or repo or schematic). 
A library is only built in RAM during the loading of a collection of
components.


Loading components:
------------------

The act of loading components utilizes the notion of inheritance and
classical file inclusion like the C++ #include.  Let's go back an
understand inheritance thinking about Java. In a Java virtual machine
each class definition container has a method table.  That table is
initially populated with methods from the base class.  As the base class
is extended some of those methods are overloaded (replaced) with ones
from the derived class in the internal method table.  Additional fields
can be introduced in derived classes also, into what is a field table
for that class.  Now lets move that conceptual model to a component. 
Lets assume we have a pin table, and a graphics table.  We give a
component the ability to inherit from: 1) a base code fragment,  or 2)
symbol or 3) component.  In this case you can do pin additions, or pin
modifications, pin swapping, in the same way you can overload a Java
class's method table.  Pins can be overloaded or replaced, and graphical
primitives can be inherited and extended.

The magic happens during the loading phase of the S-expressions, so that
the "built up" component is fully assembled in RAM by using pieces from
various places "out there", while *loading*.

If desired, the various pieces can be ear-marked with their origins in
full recognition of the existence of inheritance.  One might do this
only to facilitate graphical editing of a derived component, although if
the grammar is sweet enough, textual editing may be enough for all
editing of derived components.

Re-loading is simply done by clicking a "parse" or "show" button.  The
the parser reloads the source stream and does file inclusions as called
for.  A portion of that source stream comes from the textual UI panel. 
Inherited portions come from a library (which is now a RAM resident
concept only).


Example
-------

(component SOMENAME
  # inherit is like C++'s #include
  (inherit SOMEOTHERNAME WHERE)
  (pin 12 ... WHERE...ORIENTATION)
  (pin 13 ... WHERE...ORIENTATION)
  (pin 14 ...)
)

Pin 12 and 13 are provided here and they are overloads because 12 and 13
have already been defined in SOMEOTHERNAME.  So this could be the means
of a *pin swap*.   However pin 14 is new, since SOMEOTHERNAME did not
have one, so this is an extension. In one example we see both a)
overloading and b) extension.

This example would be a new SOMENAME component, and its graphics are
fully inherited from SOMEOTHERNAME, and can be extended here, but not
overloaded in any way that I can think up.


Where do they come from? and component versioning:
-------------------------------------------------
The ability to reference an external component by a GUID (globally
unique ID) of some kind lets you pull in components from anywhere in the
world.  A GUID inherently needs to respect versioning.  That is to say,
if you make an edit to a component that somebody else depends on, you
still have to provide the original version also.

Enter the version control system.  Since each component and component
source code fragment exists in its own file, a source code control
system is used to house these files, and they can be accessed by using a
SCCS repo, file name and version number, over the Internet, or locally.

One possibility for this is to build a tcp socket oriented bridge into
Bazaar's access API, which I assume lets you access any version of any
archived file.  Only one such server is needed for the "kicad supplied
libraries".  Behind the scenes the bridge/server simply uses launchad's
bazaar based repo.

The loading of code fragments from afar need to be cached in RAM, so the
concept of a *library* does not go away.  A library is a RAM container
that caches those things coming from afar in order to enhance speed. 
But remember, kicad supplied libraries are essentially "read only" (for
all but those with the generating scripts).  So putting them under SCCS
and in launchpad as a primary place of dwelling is reasonable for those
with Internet access.  Others could check out the library branch.


How?
----

I can have this coded by Tuesday, given enough incentive.  (I'm just not
going to say which Tuesday.)