kicad-developers team mailing list archive

[Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx>]

I think the differences expressed are about problems in communication, not
differences in actual opinions. I agree with myself (obviously), with what
Andrew said and with Ian. We are just talking past each other, about
different things.

Me said (meant): the content manager should be generic enough and have a
reusable (within reason, considering KiCad's needs) backend with a clear
API, then KiCad specific parts and UI built upon that. Just normal good
architecture, nothing more.
Andrew said: it should be integrated into KiCad for easy user experience
and targeted for KiCad end users, and be safe to use.
Ian said: it should be flexible and allow different use cases and
configurations.

As we can see, there's no real conflict.

The backend could be developed independently from the UI and KiCad specific
parts.

Eeli Kaikkonen

ti 26. marrask. 2019 klo 17.20 Ian McInerney (Ian.S.McInerney@xxxxxxxx)
kirjoitti:

> We should not limit the end points available to users to be only the KiCad
> systems we decide, and also should not constrain plugins to be open source.
> Doing this would constrain independent companies from developing plugins to
> interface KiCad with their systems if they so choose (for instance, if a
> company wanted to create a plugin to use an EM simulation package from
> KiCad to simulate the board and sell it as an extension to their product,
> baring other licensing concerns).
>
> Any plugins we provide through a KiCad official repositories could have
> the open source requirement, but the idea of a centralized repository that
> should be scoped out and discussed.
>
> -Ian
>
> On Tue, Nov 26, 2019 at 12:34 PM Andrew Lutsenko <anlutsenko@xxxxxxxxx>
> wrote:
>
>> HI Eeli,
>>
>> I've seen that thread earlier and reread it again.
>>
>> Some of your ideas have merit but I think built-in content manager should:
>> 1. Be at least somewhat coupled to KiCad needs and not be super generic.
>> We are not building apt-get repository here that has to handle arbitrarily
>> complex packaging//installing/dependency resolution behavior.
>> 2. Have some sort of central managed repository so that some rules can be
>> enforced like proper licensing and author attribution, as well as enforcing
>> open source requirement for plugins.
>>
>> Good chunk of reasoning for the above comes from security considerations.
>> For example when I download a library with built-in kicad manager I trust
>> that no arbitrary non-kicad code will be executed because there is no need
>> for library to have any code. Generic plugin manager knows nothing about
>> what files are symbol libraries and where to put them and what are 3d
>> models/footprints. Kicad plugin manager can automatically suggest to add
>> libraries to your lib tables.
>> Enforcing open source requirement for plugins is also important so that
>> any user can check what are they downloading before they do. And users
>> without the technical ability to do so will rely on community feedback
>> and/or rating system to build some degree of trust that code is not
>> malicious.
>>
>> That's not to say that "side loading" a plugin from your own
>> manifest/metadata file would not be possible. Of course it should be, even
>> just for development purposes, but then you are on your own. Being able to
>> use custom repository should also be possible.
>>
>> Of course all of the above are just my opinions and will be open for
>> discussion but it's easier to do in the google doc. I'm happy to capture
>> alternative options with their pros/cons in the doc as well.
>>
>> Regards,
>> Andrew
>>
>>
>> On Tue, Nov 26, 2019 at 2:25 AM Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx>
>> wrote:
>>
>>>
>>>
>>> ti 26. marrask. 2019 klo 11.27 Nick Østergaard (oe.nick@xxxxxxxxx)
>>> kirjoitti:
>>>
>>>> I don't know if you use freecad, if you do you probably used the addon
>>>> manager. It is quite helpful in installing python plugins.
>>>>
>>>> It is probably worth reviewing how it works conceptually.
>>>>
>>>
>>> Yes, I know about it. For me it was easier to start from scratch. And
>>> I'm a bit more ambitious than the FreeCAD plugin manager, although my
>>> skills don't always follow :)
>>>
>>> Here's a forum discussion:
>>> https://forum.kicad.info/t/one-script-to-rule-them-all/8935. Try to
>>> skip the unpleasant parts.
>>>
>>> I don't remember all the details anymore, but I think I already
>>> envisioned and maybe partly implemented more generic purpose features than
>>> I originally intended. Of course bobc was right and the manager should
>>> manage all kinds of downloadable content. One misunderstanding I would like
>>> to remove in the very beginning. This is not tied to any one central
>>> repository. It's just a matter of configuration and implementation details.
>>> The end user could configure different repositories or single package
>>> description sources. A "repository" is just one URL where several package
>>> descriptions can be found. Of course that URL should be configurable,
>>> chosen from a list etc.
>>>
>>> Eeli Kaikkonen
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>