kicad-developers team mailing list archive

[Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx>]

ti 26. marrask. 2019 klo 22.23 Seth Hillbrand (seth@xxxxxxxxxxxxx)
kirjoitti:

>
> We need to start with the API definition and file format changes.  The
> API definition should include end points and returns.  The file format
> changes should include the files and specific configuration lines
> needed.
>
> Please do not go down the road of an entirely public infrastructure
> manager.  We can include an option for additional servers that return
> the API calls, but this needs to be centralized to fit into the KiCad
> roadmap.
>

 I don't understand either of these points, could you open up them a bit?

When I played with my plugin manager I realized that the manager can be
completely agnostic about the content. It can also be mostly separate from
KiCad C++ code, it doesn't need to know the internals of KiCad, and there's
definitely no need for file format changes. Unless you talk about having
for example some repository URLs or desired installation locations in main
KiCad configuration file. KiCad should have API for refreshing the
libraries and plugins after installing new ones, not much else. Possibly
KiCad should be aware of the changing file system while
installing/removing/updating.

I don't see why these should be known first. I hoped that the content
manager could be developed mostly separately from KiCad and in python -
that would be a great strength, hopefully saving time and effort from the
main developers while drawing in new volunteers. It could indeed be a
plugin (as a proof of concept my plugin can install and update itself). It
could easily be modified afterwards to plug it into KiCad, after finding
out what it needs from KiCad and what KiCad needs from it.

What do you mean by completely public infrastructure manager? There
probably should be something preconfigured for this to be as user friendly
as possible and to fully integrate with KiCad and the official libraries
and other official content. But as for other, 3rd party, content, the only
reason to have a content manager is to allow people to add content freely,
so that a plugin writer (or anyone else) can publish an installable plugin
and the end user can install it.

What is "additional servers that return the API calls"? There's no need for
any servers apart from existing ones around the world, any server in
internet or even local hard disk which has files which can be downloaded or
copied. There's no need for any additional protocol or API for a server.

BTW, here's a link to bobc's introduction to kipi, his idea of a content
installer:
https://forum.kicad.info/t/announcing-kicad-package-installer-kipi/10193.
It follows roughly the same ideas than mine, although mine introduced the
idea of a metadata repository from the beginning.

Eeli Kaikkonen