ti 26. marrask. 2019 klo 22.23 Seth Hillbrand (s...@kipro-pcb.com) 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
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
