For me it would be important that the data that is changed on the server is recognized and adopted by KiCad. Unfortunately, English is not my native language and I may not understand exactly what you mean. Could you give me a small example of how I should understand this or a source where I can read more about it?
On Thursday, April 25, 2024 at 2:39:55 AM UTC+2 [email protected] wrote: > Hi Rosy- > > Thanks for the interesting ideas on a version 2. > > One thing that I would like to focus on is utilizing standard mechanisms > where possible. So, for example, in the section on caching, I would > strongly prefer to utilize HTTP-based header calls instead of sending the > caching data request to the web application. Here, we could utilize > If-Unmodified-Since in a GET request and properly parse the response in > KiCad (HTTP412) to see whether we could utilize locally cached data. > Similarly, using transfer encoding instead of chunking the data in the > backend will make the implementation more universal and speed for people. > > The reason for this preference is to allow the use of standard tools to > optimize content delivery without our needing to code additional logic to > support it. > > Seth > > [image: KiCad Services Corporation Logo] > Seth Hillbrand > *Lead Developer* > +1-530-302-5483 <(530)%20302-5483> > Long Beach, CA > www.kipro-pcb.com [email protected] > > > On Wed, Apr 24, 2024 at 2:57 PM Rosy <[email protected]> wrote: > >> Hello everyone >> >> I found a solution for issue >> https://gitlab.com/kicad/code/kicad/-/issues/17584 that neither changes >> the behavior of the library nor affects the performance. To do this, I >> recorded the two merge requests: >> master: https://gitlab.com/kicad/code/kicad/-/merge_requests/1914 >> 8.0: https://gitlab.com/kicad/code/kicad/-/merge_requests/1925 >> >> I have also developed a solution for issue >> https://gitlab.com/kicad/code/kicad/-/issues/17569 , which occasionally >> checks before a symbol is loaded whether the cache has already been created >> and, if not, created first. >> To do this, I recorded the two merge requests: >> master: https://gitlab.com/kicad/code/kicad/-/merge_requests/1927 >> 8.0: https://gitlab.com/kicad/code/kicad/-/merge_requests/1926 >> >> >> I think it's important that dynamic libraries like the http library can >> also add descriptions to the sublibraries. To do this, I recorded the >> following merge requests: >> master: https://gitlab.com/kicad/code/kicad/-/merge_requests/1921 >> 8.0: https://gitlab.com/kicad/code/kicad/-/merge_requests/1919 >> >> I've had various thoughts about the issue >> https://gitlab.com/kicad/code/kicad/-/issues/17570 and my other ideas. >> One of the problems with the existing solution is that certain requests >> return an array, making it almost impossible to expand. >> I could imagine shouting a v2 of the http library. Attached I have a >> document that describes how I imagine this. >> >> I would be happy to receive your feedback. >> >> On Monday, April 22, 2024 at 5:09:39 PM UTC+2 Rosy wrote: >> >>> 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/519f23dc-97bf-4ce5-8c5b-be4197c3b938n%40kicad.org >> >> <https://groups.google.com/a/kicad.org/d/msgid/devlist/519f23dc-97bf-4ce5-8c5b-be4197c3b938n%40kicad.org?utm_medium=email&utm_source=footer> >> . >> > -- 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/a66c8604-e6c3-471f-8305-54585e117846n%40kicad.org.
