kicad-developers team mailing list archive

["Mateusz" <komorkiewicz@...>]

I do agree, that on the first glance it is a good idea, but ...

The problem is that thousands of small files is not good at all (too slow both for hdd and system API).I don't think any EDA program uses one-file-one-component system.

I think all we need is a version tag in component definition. After all theproject librarian will always have to supervise the component adding process to main repo. If we manage to give him tools good enough to do that we will not need this one-file-one-component system.

I am working on a tool for online libraries repository.

Now it uses wxHTTP class to download requested components from: https://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad-library

It still needs a lot of work and discussion, so I would be more than happy if you would like to join this project.

--- In kicad-devel@xxxxxxxxxxxxxxx, "phinitnan_c" <crackerizer@...> wrote:
>
> Yes, I saw many criticism in the previous thread. To me, file system is asimplest form of database. With pre-structured (what also have be done in database), the directory would not be that complicated. Syncronizing, merging, editing ,deleting ,creating inheritance and creating categories are simpler and version control can be applied to each component using availiable tools such as cvs or svn. I also can see a lot of benefits using file and directory instead of database.
> 
> Anyway, this is just one part of the whole story. Drawing style of library and module is also important. I will wait for Vesa work and decide what Ishould contribute to the project.
> 
> --- In kicad-devel@xxxxxxxxxxxxxxx, Manveru <manveru@> wrote:
> >
> > 2009/11/4 phinitnan_c <crackerizer@>
> > 
> > >
> > >
> > > Manveru,
> > >
> > > Thank you for cleaning up my wiki page. I'm quite new to wiki and will
> > > update it soon.
> > >
> > > It seems that there has been a lot of on going in this matter. The first
> > > priority to me now is, how library/module directory are organized. Isthere
> > > any conclusion on how the directories are organized? Will we still use the
> > > old style (Many components per file)? According to khiraly proposal, I think
> > > the one component per file style has more advantages, especially for an open
> > > source project where the developers live in different places. By using
> > > directory structure, the components can be categorized in the tree-style
> > > manner. Below is my proposed structure:
> > >
> > > library
> > > |
> > > |- category1 (transistor, opamp, etc.)
> > > | |- manufacturer1
> > > | | |- component1
> > > | | |- component2
> > > | |- standard component1
> > > | |- etc.
> > > |- category2
> > >
> > > module
> > > |- category1 (pdip, soic, etc.)
> > > | |- package1
> > > | |- package3d1
> > > | |- package2
> > > | |- package3d2
> > > |- category2
> > > Recent Activity
> > >
> > > - 4
> > > New Members<http://groups.yahoo.com/group/kicad-devel/members;_ylc=X3oDMTJnYTJ1bXY5BF9TAzk3MzU5NzE0BGdycElkAzE2NzEzODI5BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMjU3MzM1Njg3>
> > > - 1
> > > New Files<http://groups.yahoo.com/group/kicad-devel/files;_ylc=X3oDMTJoM3JoZmlyBF9TAzk3MzU5NzE0BGdycElkAzE2NzEzODI5BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDdnRsBHNsawN2ZmlsZXMEc3RpbWUDMTI1NzMzNTY4Nw-->
> > >
> > > Visit Your Group
> > > <http://groups.yahoo.com/group/kicad-devel;_ylc=X3oDMTJmcXQ4NmN0BF9TAzk3MzU5NzE0BGdycElkAzE2NzEzODI5BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEyNTczMzU2ODc->
> > > Yahoo! Finance
> > >
> > > It's Now Personal<http://us.ard.yahoo.com/SIG=14hkje1lb/M=493064.12016257.12445664.8674578/D=groups/S=1707281942:NC/Y=YAHOO/EXP=1257342888/L=/B=T0_4GUSO5_M-/J=1257335688283343/K=Fs4J7_4MtcFwzohTbBrX5A/A=4507179/R=0/SIG=12de4rskk/*http://us.rd.yahoo.com/evt=50284/*http://finance.yahoo.com/personal-finance>
> > >
> > > Guides, news,
> > >
> > > advice & more.
> > > Search Ads
> > >
> > > Get new customers.<http://us.ard.yahoo.com/SIG=14ht5414c/M=493064.12016308.12445700.8674578/D=groups/S=1707281942:NC/Y=YAHOO/EXP=1257342888/L=/B=UE_4GUSO5_M-/J=1257335688283343/K=Fs4J7_4MtcFwzohTbBrX5A/A=3848641/R=0/SIG=1312g85fq/*http://searchmarketing.yahoo.com/arp/srchv2.php?o=US2003&cmp=Yahoo&ctv=Groups2&s=Y&s2=&s3=&b=50>
> > >
> > > List your web site
> > >
> > > in Yahoo! Search.
> > > Yahoo! Groups
> > >
> > > Small Business Group<http://us.ard.yahoo.com/SIG=14h10gcl8/M=493064.12016272.13586184.8674578/D=groups/S=1707281942:NC/Y=YAHOO/EXP=1257342888/L=/B=UU_4GUSO5_M-/J=1257335688283343/K=Fs4J7_4MtcFwzohTbBrX5A/A=5758222/R=0/SIG=124m43uve/*http://finance.groups.yahoo.com/group/BankofAmerica_SmallBusiness/>
> > >
> > > Improve your business
> > >
> > > by community exchange
> > > .
> > >
> > > 
> > >
> > 
> > Personally I would prefer storage in a database of some form to avoid mess
> > of complicated directory structure. I am sure that would be subject of
> > criticism.
> > 
> > Management tool shall allow export/import parts in format close to currently
> > known. Such database would be helpful if KiCad start synchronizing parts
> > with parts repositories on the web. We have open way to create an open well
> > defined standard for storing schematic symbols and parts cases data, which
> > may allow others to import to their software if they want.
> > 
> > -- 
> > Manveru
> > jabber: manveru@
> > gg: 1624001
> > http://www.manveru.pl
> >
>