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
