On Mon, Aug 31, 2009 at 6:55 AM, Andy Eskelson<[email protected]> wrote: >> 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 :-)
As I envision implementing this, none of this is really relevant. First, with a robust search feature, browsing by category would be a secondary means of finding parts anyway. If you want an ATTiny13, just search for it, you'll find it much faster than navigating ICs>Microcontrollers>Atmel>ATTiny. It doesn't matter if someone accidentally tagged the ATTiny13 as a resistor instead of a microcontroller, it will still come up when you search. But even ignoring search, it still isn't a big deal. There would be only one file where all the parts would be stored, so the concept of Libraries would not really be present anymore. There are categories, but they are simply a tag in a database. A part can be in one category or a dozen or more, however many is relevant (for example, the ATTiny could be in the categories ATTiny, AVR, and Atmel). It's certainly possible that a user could add the wrong category label to a part, but since any logged in user can make corrections to the part, this is easily fixed and once it's fixed for one person, it's fixed for everyone. > 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. Yes, I agree. I actually said the same thing later in my last email, though not quite as explicitly. Internet access cannot be guaranteed, and no one should have to stop working just because their net connection or the server is down. It should be easy for a user to automatically keep a complete copy of the repository on their local computer that is synced once a week or so. > 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. Parts would never be locked out. Doing so means that some volunteer would be required to screen the part prior to approving it. At best that means a lot of unnecessary work for volunteers, at worst it means that people get screwed up boards manufactured because the user trusted the overworked volunteer to do a good job reviewing the part. Unreviewed parts are simply flagged as such, and then it is the users job to compare the part to the datasheet. Once he's checked the part, he can rate the part in the library and it's trustworthy rating would go up. It is up to the end user to decide what threshhold he considers safe to trust a part. Some users will trust part that have been rated good by two people, others won't trust one that has been rated good by ten people. >> 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. The problem was explained fine. If you don't like the cap symbol, make a new one. But remember, if you don't like the polarized cap symbol, there's a good chance that many other people don't like it either. Why should each of those people be required to make the same change or to live with a symbol that they don't like? Instead, when you change the symbol, it is automatically added to the part as an alternate symbol. The end result is that only very rarely will you find a part with a symbol you don't like, since someone else will have had the same reaction first. In fact it would be trivial to set a preference so after you choose the new symbol once, that would now be the default for polarized caps, even if you are using a different value. There does need to be a way for a user to make changes that are only available locally, but for the majority of circumstances, the changes will probably be best if they are shared. >> 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. Reasonable point, and there should be a preference to suppress any "quiet" notifications. You probably do want to be notified of more important issues, though (such as if the part was created with the wrong footprint). >> 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. "The parts do not -NEED- to be embedded into the file". Doing so as an option is fine. I disagree with the notion of setting this as the default. I agree that if I were sending a file to my customer for review, including the parts is a good idea, but if I'm sharing a board on the Internet, including the parts is redundant. Regardless, this is an implementation detail and not a major sticking point. >> These are valid issues, but not as significant as you are making them > > 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. I may have sounded too dismissive of this issue. I don't disagree that there are issues here that need to be considered. But there are also fairly easy ways to avoid the issue. A couple important points to remember: * Standard schematic symbols are not copyrightable. * A simple Pin Number : Pin Name list is not copyrightable. * Unique schematic symbols are copyrightable. * The part itself is copyrighted, but by the part manufacturer, not the library creator. * Any text descriptions are copyrighted, though if it's taken straight from the datasheet, there is no practical violation. In other words, there are really only two main areas that I see copyright being an issue: The schematic symbol and the description. For the schematic symbol, one easy solution is to create a standard set of schematic symbols for most types of parts. ICs get one type that is automatically scaled to fit the pin count. The standard symbol can be overridden, but doing so will be noted and require extra scrutiny before getting it's trustworthy rating. The text description should be reviewed and generally should just be the text from the datasheet along with some optional notes. This could easily be edited right on the website or from withing the library browser. It's also important that you understand what is known as the 'Safe Harbor' provision of copyright law. Because this system would be relying on user contributions, the project itself could not be sued so long as we live up to the obligations defined by that law (see <http://www.chillingeffects.org/dmca512/faq.cgi> for more info). In the event that a particular part or parts were deemed to have been taken from another vendor's library, the project would be required to take down those parts, but that is easy to do. Those parts would then be added to a list of parts needing replacement, and they could then be created straight from the datasheet. Copies of those parts already in use would not be an issue for the project, since they would be excluded via the Safe Harbor provision. Theoretically, users of the copyrighted parts could be sued, but that's not really viable in practice and again easily fixed by simply updating to the new part. > now 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. Yes, but you can't do protect yourself if you don't understand the law in question. In this case, the law gives explicit protection to this sort of service. We do need to consider the legal issues, but they are absolutely not reason to prevent this proposal from moving forward. >> But then you have sort of a chicken and egg problem. You can't have > > Yes it is chicken and egg. > ... > In practical terms you will need at least one major product to take up > the system in order for it to gain any momentum. Not really. Having multiple programs using this system would certainly accelerate the rate of growth, but it is by no means required. But as of today, how many parts do you suspect that people have created for KiCAD that have not been shared with anyone? If all those parts were created in a public space, KiCAD's libraries would probably be twice the size they are today. And I've talked to more than one person who says that KiCAD intrigues them, but it's libraries are keeping them from adapting it. When you increase your library size, you increase your userbase, which leads to new parts being added, which leads to more users... >> 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. You can certainly change the pin names on an IC locally to suit a particular project. But normally those changes would be relevant to a particular project, not a universal for the part itself, and if they are universal for the part there's a good chance other users would also benefit from those changes. I see little reason (not no reason, just little) that the user would want to make changes on the part level without sharing them (remember, this would not overwrite the existing part, simply crate a variant). That's not to say you can't make local changes, just that it would generally be better if the changes are made publicly, though it is up to the user to make the final decision. > 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. All of these issues are based on a flawed understanding of what I'm proposing. The notion of 'libraries' goes away under my proposal*, and is replaced by a simple database. Do you want to override the pin names of a part in you local copy of the library? No problem, a new record is added in the "pin name" table of the database. That record would never be overwritten, because the entire library is never overwritten. Individual parts in your database would be overwritten, but only if they are not in use in any of your projects**-- If they are, the new version is downloaded, but the old version is kept as well. That way you would always have the most current version of a particular part for new projects (if you want it), but the old version remains in your library as well. You no longer "download a library file", instead you just add parts to your local database. Managing your local library of parts is now trivial, since the vast majority of it is done automatically in the background. * To be clear, the existing libraries would probably remain available at the start, though it makes little sense to maintain both systems in the long run. ** A side benefit of this feature would be that it would be easy to get a list of every part you use and in what project you use them in. Probably many other cool uses as well. Once you have a database, there are all kinds of cool things that can be done with it.
