Badr, Thank you for your patch but we are currently in feature freeze for the stable 5 release. This patch will have to wait until the stable 5 version is release and the version 6 development is opened. I'm not sure exactly when that will happen but I will review your patch then.
Cheers, Wayne On 12/24/2017 05:56 AM, Badr Hack&Invent wrote: > Hi, > Here is a patch to add the remote library management as a plugin. > I added the possibility to specify multiple urls in a single file, it > was useful for our case. > We tested this approach several weeks, it seems fine in term of > performance. > It doesn't support remote zip files as for pcbnew. I can manage to > implement it in a second time. > If this patch is ok I will write a detailed documentation on how to use it. > Regards, > Badr > > > Le 2017-08-14 15:21, Wayne Stambaugh a écrit : >> You could modify the SCH_LEGACY_PLUGIN_CACHE code to handle urls instead >> of file names. That way you could hand remote and local files in the >> same plugin. wxWidgets has classes to handle urls (wxUrl) and input >> streams (wxInputStream) which can be use as the LINE_READER >> (INPUTSTREAM_LINE_READER takes a pointer to a wxInputStream object). >> The primary drawback to this is performance. Past testing has shown >> that wxInputStream has a lot more overhead and is significantly slower >> than either our FILE_LINE_READER and std::istream so that is why we >> haven't used it anywhere. It is also why I recommended writing a new >> plugin. I'm guessing with remote I/O, the wxInputStream performance hit >> will be far less noticeable than the remote I/O time. >> >> Wayne >> >> On 8/14/2017 3:29 AM, Badr Hack&Invent wrote: >>> I see, >>> I thought it would be better to upgrade SCH_LEGACY_PLUGIN_CACHE to >>> handle remote libraries seemlessly rather than creating a new plugin. >>> I will check how to add a new plugin for remote libs without adding >>> additional actions for the user. >>> >>> Badr >>> >>> Le 2017-08-14 02:44, Wayne Stambaugh a écrit : >>>> I think you misunderstood what I was implying. You should not be >>>> looking for a different symbol library header. This is a change that I >>>> would reject since you are effectively changing the library file >>>> format. >>>> What I suggested was that you create new plugin that reads from a >>>> remote url similar to the github plugin used for footprint libraries. >>>> >>>> I also do not like the idea of a separate LoadRemote() method being >>>> added to the SCH_PLUGIN object. There is no reason to add it. All of >>>> the symbol library methods take a wxString which could be a url instead >>>> of a file name. It is not limited to files and up to the plugin >>>> type to >>>> handle it correctly. My preference is that you create a new plugin for >>>> remote files similar in concept to the github plugin. That is the >>>> whole >>>> point of the current plugin interface. Take a look at the board >>>> plugins >>>> to see the preferred method of creating plugins. >>>> >>>> I never really intended for the legacy symbol file format to have >>>> multiple plugins like the kicad board and footprint library file >>>> formats >>>> so I didn't create separate parser and formatter objects like I did >>>> with >>>> the board file formats. Nothing is preventing that from happening with >>>> the current schematic and symbol library file formats. I would not >>>> have >>>> any objection to splitting the parser out of the >>>> SCH_LEGACY_PLUGIN_CACHE >>>> object. I am planning on make the parsers and formatters for the new >>>> schematic and symbol library file format code separate so it can be >>>> used >>>> by any plugin. >>>> >>>> Cheers, >>>> >>>> Wayne >>>> >>>> On 8/13/2017 3:26 PM, Badr Hack&Invent wrote: >>>>> Hi, >>>>> >>>>> Here in the attachment the patch that add the remote lib retrieval. >>>>> >>>>> Badr >>>>> Le 2017-08-13 17:29, Badr Hack&Invent a écrit : >>>>>> Hi, >>>>>> >>>>>> Those couple of days I was checking how to update EESCHEMA to add >>>>>> remote libraries retrieval function. >>>>>> >>>>>> Since am familiar with legacy format, I updated the plugin: >>>>>> SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files. >>>>>> >>>>>> The idea was to create a new type of library >>>>>> EESchema-REMOTELIBRARY (I >>>>>> put an example in the attachment) >>>>>> The content of this library is the following: >>>>>> EESchema-REMOTELIBRARY Version 1.0 >>>>>> URL https://www.example.com/mylib1.lib >>>>>> URL https://www.example.com/mylib2.lib >>>>>> ... >>>>>> >>>>>> This lib file is saved localy and specify the path of each remote >>>>>> library you want to retrieve. >>>>>> >>>>>> The updated code seemlessly check the type of the library, if it is >>>>>> EESchema-LIBRARY it parse it like always, else if it is >>>>>> EESchema-REMOTELIBRARY it download each remote lib and parse it when >>>>>> it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY). >>>>>> >>>>>> The impacted files are: sch_legacy_plugin.cpp and >>>>>> sch_legacy_plugin.h >>>>>> -> I implemented the algo and made some tweeks to use LINE_READER >>>>>> instead of FILE_LINE_READER as argument to manage to use >>>>>> STRING_LINE_READER >>>>>> >>>>>> I also modified KICAD_CURL_EASY::KICAD_CURL_EASY() to set the option >>>>>> CURLOPT_SSL_VERIFYHOST to 0 to disable ssl certificate checking in >>>>>> https requests. This modification is not required, but was useflul >>>>>> for >>>>>> our case where our server is behind ssl without certificate on the >>>>>> domaine, just ip addresses. >>>>>> >>>>>> I made a prototype in the attachment, it is woring. >>>>>> >>>>>> I don't know if this modification is inline with the arachitecture of >>>>>> kicad? >>>>>> >>>>>> Badr >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ 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