← Back to team overview

kicad-developers team mailing list archive

Re: Online library sharing idea


On 08/08/2013 04:44 PM, Chris Morgan wrote:
> On Thu, Aug 8, 2013 at 12:12 AM, Dick Hollenbeck <dick@xxxxxxxxxxx
> <mailto: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
>     <mailto:dick@xxxxxxxxxxx>> wrote:
>     >> 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 pcbnew.
>     >>
>     >> 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?
>     SWEET
>     This design is one I wrote as a result of endless emails and thinking about it:
>     http://dev.kicad-pcb.org/sweet/
>     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.
>     Dick
> Hi Dick.
> 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 parts around.
> Chris

KiCad treats footprints and schematic parts differently.  (Yet does not prevent you from
adding references from one to another.)  So if you want "to simplify", you should have one
conversation about each realms, footprints and schematic parts.  Two separate
conversations.  One in my mind is a $100,000 undertaking, the other is a mere 3 weeks of work.

Simple is the latter.  You started by saying the remote library should work just like a
local library for access.  Let's say that is true for read only access.  For admin, you
develop your webbrowser submission and patch approval process with human intervention.
The 3 week effort includes only the read only access, as I measure it.

I don't think eeschema is a foundation that should be built upon.  So I don't wish to say
anything more about schematic part remoting, other than I will rewrite eeschema and do
sweet for $100,000.  Short of that is of no interest, you'd be building on sand.

So the conversation I can help with is the pcbnew one, and writing a "read only" http
footprint PLUGIN is quite easy IMO.  As I look at it now, there are really 3 separate
conversations.  One I don't want to have again, until there is money, a second one on read
only access of footprints, and a third one I don't care about which is the "web admin" of
the read only footprint access.  You could do the latter using github pull requests.  Keep
it easy.  There is no versioning in the footprint PLUGIN api.

Hopefully you can best utilize my time based on what I've said here.


Follow ups