> Ok, well I'll add my feedback, but I'll try to keep from going on too long. > :-)
Keep it going... all ideas are worth something. > That seems like a poor argument. Databases are very good at organizing wrong area... fine on a web site where you manage the system via some form of DB, it's the user end that causes problem. Where will a user put a mod or part? some will dump them into one place, some will split them out into different files, I'll guarantee than someone will shove the part for a micro into a lib intended for passives either by mistake or because that happened to be the last lib accessed.. I'm sure you get the idea, done it enough times myself :-) > Well, if it isn't very manageable already, that seems like a great Yes pretty much what has been said > > I agree. There are two big issues here, accessibility and security. > The libraries need to be easily downloadable, so people with > unreliable (or without) internet connections can use it. That part is > easily solved. Just make it so users can download either the entire > database or just the parts they want at any time. The security issue > is primarily that we need to know whether we can trust parts or not. > The "trustworthy rating" that I mentioned before helps with that, but > we also would need to be sure that no one could maliciously replace > the trusted part with a broken one. That's a fairly simple web > security issue, though, so it should be easily dealt with. There are several aspects to the security point. The most important part is that items used in a project MUST ALWAYS be available. So if items are downloaded and used they must get saved into the local repository. That's part of general data security i.e. ensuring that the data you need is always available. Protecting the data against changes is another aspect. things such as validating a change prior to making it available as you mention. The trustworthy part is another mechanism to help validate a part but that might get wrapped up into the system that locks out changes. Six of one half a dozen of the other I think. > > All these are simple variants. There's no reason at all my proposed > system couldn't have variants. But unlike the current system, those Prob not very well explained on my part... Users will take an existing part and change it to their own taste, and then they will save it back under the SAME NAME as before. i.e. I don't like the polarised cap symbol of an open box and a curved line I prefer the open box and the filled in box symbol. So I change the capapol lib and everything uses my preference. So you need to think about how a system could work around that. There are ways, but it's going to need a lot of careful thought. It's not so much about having a number of versions on the web site, but more of how you are going to handle local changes without things getting totally confused. > > Updating is an issue with the current system, but not with my ... That's getting along the sort of lines that need to be considered. I'm not sure that I would ever want notifications as once a part is in use then it will be OK for a particular project, but that's detail. > change without my permission. If I ever share the schematic or board > files, the parts do not need to be embedded into the file, since the NO totally unacceptable. Any file must be totally transportable without access to any external system. Doing it any other way will cause all sorts of problems. I'll allow (but not happily) an option, NOT A DEFAULT, for a file to be saved without libs and parts for the express purpose of reducing file size, but for many projects the file sizes are not that big anyway, and as they are generally text type files they compress very well with existing archiving tools, so size is not normally an issue. > > These are valid issues, but not as significant as you are making them They are very significant, Wiki is a different animal where people are generally writing up original text, (well hopefully as that is what wiki was intended to be) they also have a staff to deal with any problems. With things like parts and mods, you are dealing with a fairly small set of players in the PCB design sox field. So are going to need to be red hot on any possible infringements on submissions into your system. Other providers of PCB design tools may not be at all happy if they find their libs converted and uploaded to a rival system. Naturally in the case of a component manaf. providing libs, the situation is different, however even there the rights need to be checked. There is a big difference between such libs being made available for people to use, and grabbing these libs and putting them up on another system. Some companies may want to retain control of their libs, and prohibit them from appearing on other systems. I know this sounds like a load of unnecessary twaddle, but lawyers make a big living dealing with such issues. You have GOT to protect your backside. > everyone involved. But it has to start someplace, and KiCAD seems to > be as good a place as any. :-) Can't argue there :-) > > But then you have sort of a chicken and egg problem. You can't have Yes it is chicken and egg. Firstly Kicad is NOT set up to easily integrate an external source into it's lib and mod system. That gives you two options. 1. Discuss with the developers and all, to change the way kicad operates, to enable the functionally that would be needed to enable the use of the system. 2. Design and build a system to be a generic repository and hope that you have enough functionality that authors of PCB software will build in the support for it. In practical terms you will need at least one major product to take up the system in order for it to gain any momentum. > > Easily handled with a simple database field, though the 'trustworthy Don't confuse what is going on at the local user end with the web store end. The very nature of the system is that users will be changing things locally, and they will NOT submit most of these changes to the website, generally because they are will be cosmetic, or functional due to circuit considerations such as pin function changes which would be pointless uploading to the site. What I think is needed to enable this sort of project is: A system that allows the editing of a library or module as a single entity, and handles the inclusion of that item into the appropriate lib or module. A simpler means of controlling which modules and libs are searched by the system A duplicate set of libs and modules that are deemed to be "USER" types. These would never get overwritten automatically, and they would automatically get searched along with the main libs. A part with the same name in a User lib would have a higher priority than a part in the main lib. There are other tricks that you could apply, such as have a option to always use the user part and not even show the main lib part and so on. This would allow a standard set of libs to be used, and also provide the user with a means of grabbing additional libs, and also variations of parts which the user would download and include in their own USER set of libs. I think that once you have something like this then you would have the basic tools needed to make use of a web repository. Andy Andy
