Hi, Thanks all for your input. Wayne, if the I/O is abstracted and well maintainable, as you mentioned, would you support this? If no, what are the reasons?
Carl On Mon, Sep 22, 2014 at 6:56 PM, Wayne Stambaugh <[email protected]> wrote: > On 9/22/2014 5:37 PM, Cirilo Bernardo wrote: > >> ________________________________ > >> From: Carl Poirier <[email protected]> > >> To: Cirilo Bernardo <[email protected]> > >> Cc: KiCad Developers <[email protected]> > >> 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 > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
