kicad-developers team mailing list archive
Mailing list archive
Re: [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE
Did you have a chance to give a look at this patch?
>From our side we are using it almost a year now, it works fine.
Else, I don't know if an equivalent function is now under going in the
If so, I will be glad to help in testing.
Le 2017-12-24 15:31, Wayne Stambaugh a écrit :
> 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.
> 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
> 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.
> 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.
> 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.
> 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
> 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
> point of the current plugin interface. Take a look at the board
> 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
> so I didn't create separate parser and formatter objects like I did
> the board file formats. Nothing is preventing that from happening with
> the current schematic and symbol library file formats. I would not
> any objection to splitting the parser out of the
> 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
> by any plugin.
> On 8/13/2017 3:26 PM, Badr Hack&Invent wrote: Hi,
> Here in the attachment the patch that add the remote lib retrieval.
> 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
> -> I implemented the algo and made some tweeks to use LINE_READER
> instead of FILE_LINE_READER as argument to manage to use
> 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
> 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
> 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