On Wed, Aug 21, 2013 at 10:14:04AM -0400, Chris Morgan wrote: > - Using the filename to build the footprint name sounds like a great idea.
Also the sanest one, IMHO > - Lorenzo, your writeup is good and you should put that up on a kicad > wiki somewhere. I'd feel bad if your write up wasn't used elsewhere as > I was referring to names in a more generic sense. Let me provide a few > concrete examples that maybe we can discuss around. No idea if such a wiki does exist. These are my current working (production) practices, anyway, so at least they are tested:D > - Use case 1. Github repository used directly > -- Directory hierarchy might indicate the part family (connectors vs. > ICs vs. displays etc), or not. Usual library taxonomy. If it should be organized by manufacturer or component is a logistic issue; IIRC Eagle is manufacturer-rooted, but that is not necessarily the best way to handle it. > -- Because this is a filesystem we can't have more than one footprint > in a given directory with a given name. If we wanted to have more than A rule like 'no same named footprint per library' is reasonable. Precedence between libraries is AFAIK one of the reason for the new fp table (I think). > --- Different file names Good luck with that. I think that the library should be organized by the 'owner' of the library. If you don't like my part use one from another lib. So maybe, same name, different library would be a better idea (think about a branched repository) > --- Ability to look into the footprint git history. I'm not sure this > is a valuable approach. Especially considering the format of a git 'revision'. Also what if it need to be updated? > - Use case 2. Web site generated repository Do you mean a site creating a view on the underlying footprint database? > -- Directory hierarchy might indicate part family. Might also reflect > the maturity of the parts, /stable vs. /unstable directories etc. This > can be pretty dynamic. Debian package archive:D you just described that! > -- We should expect that as-of-yet unknown requirements will dictate a > dynamically generated format that we didn't anticipate so we want to > at least consider that there might be really odd dynamic layouts > generated. May be useful at least for searching stuff. > I'm not sure if the dynamically generated repository is going to be a > big issue on the kicad side or not. >From the kicad side I see only requesting URLs somewhere. If that somewhere gives a static list file or something CGI built I don't see what would matter for it. Want to get a package? just GET http://library.kicad.org/packages/WONDER-PACKAGE and it should spit down the sexp for the package. Searching would happen querying an 'appropriate' URL. -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
