kicad-developers team mailing list archive

[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