kicad-developers team mailing list archive
Mailing list archive
Re: Online library sharing idea
On Thu, Aug 8, 2013 at 12:12 AM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> On 08/07/2013 05:25 AM, Chris Morgan wrote:
> > On Tue, Aug 6, 2013 at 9:50 PM, Dick Hollenbeck <dick@xxxxxxxxxxx>
> >> On 08/06/2013 06:40 PM, Chris Morgan wrote:
> >>> Hello.
> >>> Sites like http://www.kicadlib.org/ are great for sharing libraries
> >>> but I was thinking that having integrated online library sharing could
> >>> better distribute the work while making it easier to share and use
> >>> parts. A user could add add trusted sources to their remote libraries,
> >>> contribute new parts, vote on parts etc.
> >>> Thoughts? It would probably take a bit of effort to spec out and
> >>> implement things, I was thinking of an indiegogo or kickstarter
> >>> approach to fund the work.
> >>> Chris
> >> This has been discussed numerous times, both for eeschema and for
> >> In fact I mentioned it for pcbnew about 4 days ago again.
> >> The eeschema conversation is longer, and archives have it already.
> > I've done a couple of searches like "kicad online library" and "kicad
> > network library" that didn't turn up anything. Were different terms
> > used in the discussion?
> This design is one I wrote as a result of endless emails and thinking
> about it:
> In the source tree you find the doxygen source to this design document
> named new/design.h
> SWEET is different than PRETTY in that SWEET is designed to be human
> writable, human
> readable. Whereas PRETTY was intended only to be human readable.
> In the end, I decided that eeschema needed to be rewritten, not adapted.
> This is where
> you start in a new directory and start over, but are free to copy pieces
> from the original
> work with scrutiny and refinement as you go.
> It ended up being too much work for me to fund. Get about $100,000 and I
> might be
> interested in doing the work. Some of it is done already however, the
> parser and I
> started writing a GAL client before GAL was a good as it is now.
I went through the documents and it looks like an interesting approach to
versioning parts. Clearly you've spent a lot of time building that up. I'm
wondering if we should consider using a simpler, full part, versioning for
the first round of any client/server api. It might not be as efficient but
it would likely simplify the implementation and make it easier to move