kicad-developers team mailing list archive
Mailing list archive
Re: Plugin/3rd party content manager
API definition and file formats are second step. We need to agree on
supported use cases, high level data flows, systems pieces involved.
Thing with public infra is that it's easy to move it to private infra but
not the other way around. So it's best to design as much of the system as
possible to be runnable on public infra. And I believe almost everything
can be done there. But let's discuss this after I share my design.
On Tue, Nov 26, 2019 at 6:19 AM Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
> On 2019-11-25 17:46, Andrew Lutsenko wrote:
> > Hi Seth,
> > Yes, I planned to write up my design in google doc and open it to
> > comments. I think that works best for public discussion, even though it
> > requires having a google account.
> > Design I'm thinking about requires 0 custom backend work. It will rely
> > entirely on publicly available infra such as github/gitlab hosting and
> > ci/cd pipelines. Admittedly that imposes some limitations on what we
> > can do (and I will outline them in my doc) but we can always add custom
> > backend system later to complement free infra.
> > Assuming design is accepted I am interested in doing at least a
> > minimally functional implementation. I have a lot of ideas but some of
> > them will have to be implemented later because it's not a trivial task.
> > Ok, I'll start working on it and will hopefully share the doc by end of
> > this week.
> > Andrew
> Hi Andrew-
> 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
> 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
> Seth Hillbrand
> KiCad Services Corporation
> +1 530 302 5483 | +1 212 603 9372