kicad-developers team mailing list archive

[Chris Morgan <chmorgan@xxxxxxxxx>]

On Wed, Aug 14, 2013 at 6:29 AM, Miguel Angel Ajo Pelayo
<miguelangel@xxxxxxx> wrote:
>
> 2013/8/14 Chris Morgan <chmorgan@xxxxxxxxx>
>>
>> <miguelangel@xxxxxxx> wrote:
>> > (please use nbee/nbeepass as credentials)
>> >
>> > http://kicadhub.com/pcbs/2
>> > http://kicadhub.com/assembly_guides/3
>> > http://kicadhub.com/components/107
>> > http://kicadhub.com/kicadnetlists/2
>> >
>> > 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?
>>
> That's exactly my idea right now, but I must clean up, add license headers,
> and put API keys into config files, and keep empty keys on the repo itself.
>
>>
>>
>> > 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.
>>
>
> Yes, most probably would be a good idea keeping all versions of everything
> on the exported git repo, this way you can always access the most popular
> one or know derivatives. (derivative tracking can be handled on the server
> db)
>
>>
>> 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.
>
>
> They can delete/rename parts, but they become derivatives  with a parent
> part, (just an idea)
>
>>
>> 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.
>
>
>
>
> --
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo


Please let me know when/if you get this code out there so I can take a
look. In terms of implementation it might make sense to work with Joe
Ferner, the guy behind kicadcloud.com, since it looks like kicadcloud
is trying to do basically what we are trying to do.

Chris