| Thread Previous • Date Previous • Date Next • Thread Next |
Hi - please see below On 01/02/2011 19:40, Dick Hollenbeck wrote:
Simon> I think we are along the same lines perhaps SERVER_LIB_SOURCE rather than HTTP_LIB_SOURCE.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 GoodfellowThe 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> 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.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> 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.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> 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.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> 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.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 _______________________________________________ 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
| Thread Previous • Date Previous • Date Next • Thread Next |
