kicad-developers team mailing list archive

[Chris Morgan <chmorgan@xxxxxxxxx>]

>> -- Because this is a filesystem we can't have more than one footprint
>> in a given directory with a given name. If we wanted to have more than
>
> A rule like 'no same named footprint per library' is reasonable.
> Precedence between libraries is AFAIK one of the reason for the new fp
> table (I think).
>
>> --- Different file names
>
> Good luck with that. I think that the library should be organized by the
> 'owner' of the library. If you don't like my part use one from another
> lib. So maybe, same name, different library would be a better idea
> (think about a branched repository)
>
>> --- Ability to look into the footprint git history. I'm not sure this
>> is a valuable approach.
>
> Especially considering the format of a git 'revision'. Also what if it
> need to be updated?
>

Right. I'm not sure how that would work either.



>> - Use case 2. Web site generated repository
>
> Do you mean a site creating a view on the underlying footprint database?
>

Yes. Imo having github support makes it easy to enter the market of
parts but managing the part library is real problem. I'm not sure I
see a better approach than having some system that generates the
github view based on some criteria.



>> -- Directory hierarchy might indicate part family. Might also reflect
>> the maturity of the parts, /stable vs. /unstable directories etc. This
>> can be pretty dynamic.
>
> Debian package archive:D you just described that!
>
>> -- We should expect that as-of-yet unknown requirements will dictate a
>> dynamically generated format that we didn't anticipate so we want to
>> at least consider that there might be really odd dynamic layouts
>> generated.
>
> May be useful at least for searching stuff.
>
>> I'm not sure if the dynamically generated repository is going to be a
>> big issue on the kicad side or not.
>
> From the kicad side I see only requesting URLs somewhere. If that
> somewhere gives a static list file or something CGI built I don't see what
> would matter for it. Want to get a package? just
>

This querying to get the list of files/directories is something I'm
not sure we've explored. Maybe Dick can chime in on how this was
supposed to work with the pcbnew github plugin. Its important to me
because the github api appears to present such a list via the tree
api. All of the github APIs expect and return data in json format so
those wouldn't be able to be used directly.

> GET http://library.kicad.org/packages/WONDER-PACKAGE
>
> and it should spit down the sexp for the package. Searching would happen
> querying an 'appropriate' URL.
>

For github this appears possible with a url like:

https://raw.github.com/<project name>/<path>/<file>

But again, if the list comes from the github tree api then you'll
probably want to use the blob api to retrieve the part data.


Fyi, I'm building a document that tries to fill in everything that has
been discussed so it doesn't have to be researched from the mailing
list.

Chris