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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
