kicad-developers team mailing list archive
Mailing list archive
On Wed, Aug 14, 2013 at 3:34 AM, Miguel Angel Ajo Pelayo
> I'm thinking too, I really *love* the idea, and I'm sure that building on
> the simple idea -later, with time- we can do even more.
> But a simple github connector it's a great start.
> I have a piece of code that I put together some time ago (over a single
> weekend), to make a kicad-service website, that I will open at some time:
> (please use nbee/nbeepass as credentials)
> [it's ruby written, with shell scripts in python to use the kicad python api
> for rendering and gathering information]
> My plan /at that time/ was to make an aggregator of kicad projects (crawling
> github via api + octopart api) to make them documented (assembly guides +
> priced boms, etc..). And also a library part aggregator, where you could
> vote, comment, and auto-categorize (by pitch, number of pins, pin
> distribution, function, etc..)
> But at this time I thought that my time was rather limited and that I was
> better spending it at kicad itself, finishing and polishing what I started,
> so I stopped it.
Interested in putting the server code out there so everyone can take a
look at it?
> Now if we mix my old idea, with this new approach:
> Everybody has his own github library repositories, and then we could build a
> community aggregator, where you can add your git url, it keeps your parts
> synced to the aggregator, it also keeps track of voting, pulls your library
> updates, and builds an index/categorization that kicad can read,
> then it re-exports on a single github repo (agreggated) and later, exports
> an API (extension of the git idea) to keep track of votes, comments, etc.
> That aggregator might need a server (quite scalable as we relay fileserving
> to github), but it must be fully open, same kicad license, so anybody could
> build his own server if wanted (for example, within companies...)
Keep in mind that people may do unfortunate things to their github
libraries, such as delete them, change parts etc. That's part of why I
was thinking the server would want to store the data itself.
The analogy I was thinking of was a pool of parts of varying ratings
and authorship. The server could look to kicad as if it were a single
github repository but could use user accounts to protect against the
wrong people deleting/renaming parts. As the api is open there
wouldn't be any issue if someone or some organization wanted to copy
parts from one repository to another but imo if we had an official
kicad blessed repository that might be the central go-to place that we
could build into the plugin as a default source.