My goal is that the library remains compatible with existing APIs but that
the various issues can be solved. I think it is important that the same
functions as the standard functions are available for the http libraries.
The issues mentioned show where this is currently not possible.
I also find it an important function that a description can be given for
the categories, as is the case with the standard libraries. I haven't
entered an issu for this but have already added an MR.
Something that I noticed and that I would certainly like to change is that
at the moment the parts are stored in different caches with different
loading states.
There should only be one part cache.
I currently have the idea that another key called “fields” can be returned
by the API when the root request is made. Only if this is sent by the API
will the new features be activated, then the field list can be preloaded
via a new endpoint. This enables short field keys even for fields with long
names.
I would also like to introduce modify fields that allow only those parts
that have undergone updates to be reloaded.
The communication could look something like this:
# root
{
"categories" : "",
"parts" : "",
"fields" : "" //activate new fields features
}
# fields.json
{
"reference":{
"show" : true,
"default_show_name" : false
},
"value":{
"default_show" : true,
"default_show_name" : false
},
"footprint":{
"default_show" : false,
"default_show_name" : false
},
"datasheet":{
"default_show" : false,
"default_show_name" : false
},
"description":{
"default_show" : false,
"default_show_name" : false
},
"keywords" : {},
"mfn" :{ //must be unique
"name" : "Manufacturer Number", //must be unique
"show_on_chooser" : true, //only needed if not false
"default_show" : false, //only needed if not false
"default_show_name" : false //only needed if not false
},
"mfurl" : { //must be unique
"name" : "Manufacturer URL", //must be unique
"show_on_chooser" : false, //only needed if not false
"default_show" : false, //only needed if not false
"default_show_name" : false //only needed if not false
}
}
# categories.json
[
{
"id" : "1", //must be unique
"name" : "Resistor", //must be unique
"description" : "Thick Film SMD Resistors",
"modify" : 1713798563 //datetime seconds since 1.1.1970
},
{
"id" : "2", //must be unique
"name" : "Capacitor", //must be unique
"description" : "SMD MLCC Capacitors",
"modify" : 1713798563 //datetime seconds since 1.1.1970
}
]
# /parts/category/{category_id}.json
{
"parts":[
{
"id" : "1", //must be unique
"name" : "MF-ab123", //must be unique
"modify" : 1713798563 //datetime seconds since 1.1.1970
"value" : "12k",
"description" : "Tick Film SMD Resistor 12kΩ, 1%",
"keywords" : "12kOhm",
"mfn": "ab123"
},
{
"id" : "2", //must be unique
"name" : "MF-ab102", //must be unique
"modify" : 1713798563 //datetime seconds since 1.1.1970
"value" : "1k",
"description" : "Tick Film SMD Resistor 1kΩ, 1%",
"keywords" : "1kOhm",
"mfn": "ab102"
}
]
}
parts/{part_id}.json
{
"id" : "2",
"symbolIdStr": "passive:R",
"exclude_from_bom": "False",
"exclude_from_board": "False",
"exclude_from_sim": "True",
"fields":{
"reference":{
"value" : "R", //can not be empty or a number
"show" : true, //only needed if not default
"show_name" : false //only needed if not default
},
"value":{ //only needed if not default for show or show_name
//value ignored if is preloaded
"show" : true, //only needed if not default
"show_name" : false //only needed if not default
},
"footprint":{ //only needed if exists or not default for show or show_name
"value" : "resistor:R", //only needed if exists
"show" : false, //only needed if not default
"show_name" : false //only needed if not default
},
"datasheet":{ //only needed if exists or not default for show or show_name
"value" : "$(DATA)/part.pdf", //only needed if exists
"show" : false, //only needed if not default
"show_name" : false //only needed if not default
},
"description":{ //only needed if not default for show or show_name
//value ignored if is preloaded
"show" : false,
"show_name" : false
}, "mfn" :{ //only needed if not default for show or show_name
//value ignored if is preloaded
"show" : false, //only needed if not default
"show_name" : false //only needed if not default
},
"mfurl" :{
"value" : "http:mfn.com",
"show" : false, //only needed if not default
"show_name" : false //only needed if not default
}
},
"order" : {
"mfn", "mfurl" //define the order in witch the filds are added to the
symbol
}
}
On Monday, April 22, 2024 at 4:23:59 PM UTC+2 [email protected] wrote:
> Hi Rosy,
>
> > I would be happy to invest time in revising the http library so that the
> various problems can be solved, but I would like to know who I should talk
> to so that the work is not in vain but is then accepted?
>
> This list is a good place, please say more about what you propose to
> do before you start work.
>
> I have been away from KiCad this past week and haven't had the chance
> to look at the MRs yet. Maybe other developers will also chime in
> here.
>
> -Jon
>
> On Mon, Apr 22, 2024 at 2:06 AM Rosy <[email protected]> wrote:
> >
> > In the meantime I have familiarized myself with the existing solution
> and the code. It is now clear to me what the problem with 17569 is.
> >
> > I would be happy to invest time in revising the http library so that the
> various problems can be solved, but I would like to know who I should talk
> to so that the work is not in vain but is then accepted?
> >
> > On Friday, April 19, 2024 at 9:36:39 AM UTC+2 Rosy wrote:
> >>
> >> Hello everyone
> >>
> >> I currently use KiCad privately and would like to use it in our company
> in the future.
> >>
> >> It is important that there is a good solution to manage the libraries
> centrally. The http library is ideal because it enables a clean separation
> of frontend and backend.
> >>
> >> Unfortunately, there are still a few things that I think need to be
> improved a bit.
> >>
> >> I have currently created a merge request with which it is now possible
> to provide the http sublibraries with a description, which I consider to be
> an essential function and hope that it will be accepted promptly.
> >>
> >>
> >> I have also recorded the following issues regarding the http library.
> >>
> >> https://gitlab.com/kicad/code/kicad/-/issues/17584
> >>
> >> https://gitlab.com/kicad/code/kicad/-/issues/17570
> >>
> >> https://gitlab.com/kicad/code/kicad/-/issues/17569
> >>
> >> For issues 17584/17570 Andre Iwers and I have submitted the merge
> request
> >> 1910/1912/1914
> >> A possible solution has been developed, which is currently being
> discussed in MR 1910, as opinions differ on fields that are only displayed
> in the Choose Symbol dialog.
> >> What is your opinion?
> >> Otherwise, I would be happy to work out another solution.
> >>
> >> Does anyone have some tips for where and how I could tackle problem
> 17569?
> >>
> >> Thank you for your feedback.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "KiCad Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected].
> > To view this discussion on the web visit
> https://groups.google.com/a/kicad.org/d/msgid/devlist/a801fafd-930f-4b75-b718-2e706a06a0efn%40kicad.org
> .
>
--
You received this message because you are subscribed to the Google Groups
"KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/kicad.org/d/msgid/devlist/486e2d9b-0847-4b77-a566-93f9ad5f7752n%40kicad.org.
