kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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