kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/22/2014 5:37 PM, Cirilo Bernardo wrote:
>> ________________________________
>> From: Carl Poirier <carl.poirier.2@xxxxxxxxx>
>> To: Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx> 
>> Cc: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx> 
>> Sent: Tuesday, September 23, 2014 7:23 AM
>> Subject: Re: [Kicad-developers] 3d models in .pretty repositories?
>>
>>
>>
>> 3D models could be retrieved only as needed, like footprints. I don't see how this would be more polluting than in kicad-library which is installed locally.
>>
>>
>> I know the github plugin serves only footprints. That's why I wonder how hard it would be to adapt it.
>>
> 
> 
> The issue is how to adapt things so that they are useful and not make the code
> unmaintainable. If 3D models are to be retrieved from the network then this
> will touch the 3Dviewer, VRML exporter, and in the future the IDF exporter; no
> one wants to maintain network related code in all these tools.
> So first of all we need to abstract things so that at least these 3 tools
> are not really aware that they are performing a network access - so I would
> look into abstracting the file loading operation and investigate if it is
> possible to do this for the current footprint code as well as the VRML and IDF
> code. To speed up operation it would be good to create local copies as data is
> downloaded and this local cache must be checked before downloading a model on
> the network - once again this can be done via a file loading abstraction.
> It would also be good to check md5 hashes of the data and allow the users to
> update a model if desired.
> 
> This file loading abstraction might also serve eeschema in the future for
> accessing schematic symbol files. I think that doing a good job of implementing
> 3d model downloads via the net is not a small job. Although a quick hack will
> not be that difficult I don't believe it would be maintainable either, especially
> not as tools using 3d models are added in the future; I don't think anyone
> wants to create yet another refactoring job.
> 
> - Cirilo

I do not support the idea of saving models in pretty libraries.  I also
reject the idea of using PCB_IO for loading 3D models.  I do support the
idea of abstracting out any useful low level code from the IO_MGR object
to create an I/O architecture for 3D models or any other place where it
makes sense.  3D model I/O and footprint library I/O are not
interchangeable and I do not want the 3D I/O polluting the footprint I/O
code.  I know that Tom has proposed a plug in model that may serve this
purpose as well.  I don't know if he has made any progress on this front.

At some point the IO_MGR concept will be used for schematics and
component libraries.  I believe I added this development road map

Wayne