On Fri, Aug 9, 2013 at 12:45 PM, Chris Morgan <chmor...@gmail.com> wrote: > On Fri, Aug 9, 2013 at 5:02 AM, Andrew Seddon <and...@circuithub.com> wrote: >> >> I can tell you a few key design decisions we made which might help. >> >> - Lib must be cached user side, lack of internet shouldn't stop you >> designing. Files work fine, you dont need to invent a new protocol.
I really love this aspect of CircuitHub and this is the reason why I'm not so terribly interested in KiCad consuming CircuitHub's web service API. Given that your web interface is user-friendly enough and parts get saved to my filesystem, that's all I need. KiCad could simply feature a link or two pointing to CircuitHub at the relevant places of the GUI. That'd take no time to implement. >> - Footprints are defined as code(JavaScript for us). We use a tree based >> template system, so you can refactor common elements such as IPC >> specifications into base footprints and then derive specific footprints from >> the base. This will be exposed to users in a few days so you'll see exactly >> how it works and be able to inspect code for templates. >> >> I consider this pretty revolutionary, it's definitely worth stealing ;-) Is this template based system a footprint generator of some sort? As harsh as it may sound I think common package types shouldn't be allowed to be submitted, only generated. There's almost an infinite combinations of package types, pin numbers, pin pitches and various parameters. Not only that but laying down footprints of many pins / pads is considerably error prone. It'd be so much better to simply say: I want TQFP-32 with 0.5mm pitch generated whose pins are: pin 1 is VCC, pin 2 GND, ..., pin 31 is MOSI, pin 32 is MISO. >> - When CircuitHub shows you a footprint it tells you why you are seeing >> it, i.e "Approved by Chris for this part". In future we are going to >> implement trust networks where you can explicitly trust individual >> users/organisations and thus see content from those users more prominently. >> >> - The primary GUI should be browser based, resist the urge to bundle >> everything into one big monolithic EDA tool. We embrace the Unix philosophy >> of small sharp tools that talk to each other. >> >> - A Symbol/Footprint/Part(MPN) must be explicitly tied together. We call >> this a Component. Do not allow multiple entities of each type in this >> relationship. >> >> That's a few things that come to mind anyway. >> >> >> > > > I've completed a draft of a writeup on the idea, > http://chmorgan.blogspot.com/2013/08/an-idea-for-kicad-library-crowdsourcing.html > > I did talk a little bit about the file based approach. There are some things > that weren't clear, such as how to push changes from client to server with > that approach, how filenames are managed etc. > > Chris > > -- László Monda <http://monda.hu> _______________________________________________ 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
