kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 02/01/2011 01:40 PM, 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.
>
>
> 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.

Actually LIB_TABLE class allows cascading of table fragments.  You do not
even need a globally accessible library table, just put it in the schematic,
and all team members will stumble onto the same LIB_SOURCEs magically.  
(But intentionally.)


Well this is a reproduction of information already available elsewhere, and
I have other work to do.

Lastly, if you want your UUID, put it in as a part property, along with your
mother in law's first name if you want, assuming she was, for example, the
author or designer of the part.

Dick