← Back to team overview

kicad-developers team mailing list archive

Re: Kicad Library Concept Ideas

 

Hi - please see below

On 01/02/2011 19:40, Dick Hollenbeck wrote:
On 02/01/2011 01:14 PM, Mike Goodfellow wrote:
Dick, Wayne&  Jean-Pierre,

A week ago Simon Rogers posted on the developers mailing list regarding
some ideas with the Kicad library. A "we" was mentioned in the post, well,
the "we" is made up of Simon and I - we both work together at the same
company and have used Kicad for a while now.

Anyway, onto the ideas. I have attached an overview document to this post,
which outlines our ideas. I think what is important and needs to be
stressed is that as it stands, we do not want to change anything
fundamental in Kicad - instead, our work builds on functionality for the
future. In fact, the idea of the sweet parser is perfect, and we require
this to move our ideas forward. Furthermore, if there comes a time where
it is ready to be merged into the main branch it can be done with
relatively small modifications of the underlying application core, as I
think you will be able to see.

However, we would really like to open up the floor for comments on our
proposals. We have been thinking about it for a while now. We have more
detailed design documentation (in the form of pictures and flows), but
these are not entirely ready for the public domain just yet (have been
moving house this last week, and paid work has been getting in the way :-/ ).

Please, if you have any questions or comments, let us know and we will
endeavour to explain ourselves better! :)

Kind regards,

Mike Goodfellow


The part server is not adding anything new.  But rather it is and has been
expected.  The LIB_TABLE and LIB API's were designed to facilitate this.
Don't be surprised to learn that I have a lot of experience with distributed
systems, specifically CODING them.
Simon> I think we are along the same lines perhaps SERVER_LIB_SOURCE rather than HTTP_LIB_SOURCE.

a) A UUID (Universally Unique Identifier) – this will be used to identify
the part and this will be what the API calls to request from the library
manager to see if the part exists on it. We propose using Boost UUID's. See
http://www.boost.org/doc/libs/1_42_0/libs/uuid/uuid.html


Dick>  I do not think this is necessary nor desired.  I had started with
GUIDs, and moved away from it.  You can make your library table globally
unique and accomplish the same thing.  The logical name lets you move a
library without having to redo a schematic.   The discussion about how the
composite library table gets assembled can address these needs, and that
strategy is not locked down yet.  A team could have a library table out on
the web someplace which would define the mapping of logical to full_uri in a
consistent way for all team members.

Simon> OK - Why not make the part globally unique? The library structure could then change daily, hourly. Conceptually isn't the organisation into libraries then say sub-libraries such as "passives" or "resistors" only an abstraction for the user? This was why we wanted to keep information about the library structure out of the part reference.Quite possibly we don't understand your thinking.
b) (TBD) A Checksum (Possibly in the form of an MD5 hash) – this will allow
the repository to inform the user if the part has changed for any reason
(/if the part hasn't changed when the library manager code checks the cached
copy against the repository's checksum, then the local cached copy can be
loaded directly, therefore saving time/).


Dick>  We have versioning in the API now.  So I don't get this one at all.

Simon> We suggested this approach as it might be easier to compare a checksum rather than a text field - a user may use "Ver A, Ver B, Ver C" rather than "Ver 1 , Ver 2, Ver 3" for versions. The sweet text field would then be used to allow a user to decide whether to update his schematic is the part had changed.
c) The repository where the part was originally located – this will allow
the part to be found much faster, and remove the need to enumerate through a
number of repositories to find the component each time. This is also stored
as a UUID which the repository sends to the client when it is added.


Dick>  "Found much faster".....   than what?  Let's race and see who wins.

Simon> Sorry - not clear here - if you had say 10 library sources by holding a reference to the original library Kicad could go directly to this library rather than each on in turn and would therefore be faster and more efficient.

I do appreciate your enthusiasm, but I don't see anything here that would
actually constitute an improvement on first reading.  If you want me to read
it again, I will.

Simon> Thank you for taking the time to read it in the first place. I suspect that we are not too different in our thinking it's probably that email isn't an easy medium convey ideas in either direction.Sorry if we are going over old ground.
Dick




_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



Follow ups

References