kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.


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.


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.



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.


Dick