← Back to team overview

kicad-developers team mailing list archive

Re: [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

 

Maybe submit it as a MergeRequest on gitlab.

ons. 20. maj 2020 12.16 skrev Badr Hack&Invent <badr@xxxxxxxxxxxxxx>:

> Hi Wayne,
>
> Is there any update regarding this patch?
>
> If there is any thing else to adjust please let me know.
>
> For information, the plugin is working without any bug since 2018 in my
> for :)
>
> Regards,
>
> Badr
>
> Le 2018-10-30 11:07, Badr Hack&Invent a écrit :
>
> Hi Wayne,
>
> 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
> version 6?
> If so, I will be glad to help in testing.
>
> Regards,
>
> Badr
>
> Le 2017-12-24 15:31, Wayne Stambaugh a écrit :
>
> 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@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
>
>
>
> _______________________________________________
> 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
>

Follow ups

References