kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 10/29/2018 9:30 AM, John Beard wrote:
> Hi,
> 
> I have a question about the PLUGIN interface. Currently, the board
> loader looks like this:
> 
>     BOARD* Load( const wxString& aFileName, BOARD* aAppendToMe, const
> PROPERTIES* aProperties )
> 
> This means that it's quite difficult to use these methods in-process,
> as you have to write out to file in order to then parse it, which
> substantially increases time and complexity to parse data that comes
> from in-memory (e.g. a test harness, in-process decompression streams,
> stdin, named pipes or a network stream, etc).

Under the hood, the plugins (at least the kicad plugins) use output
streams.  There are OUTPUTFORMATTER objects for writing to wxString and
wxOutputStream objects.  Deriving new OUTPUTFORMATTER objects is trivial
if you wish to format to a c++ ostream object.  The PCB_IO object
interface allows you to pass your own OUTPUTFORMATTER object instead of
using the PCB_IO interface for just this purpose.  I probably should
have broken out the FORMATTER part of the PCB_IO object code to a stand
alone object like I did with the PCB_PARSER object so it would be
obvious that it is used to write to any OUTPUTFORMATTER but it does
support writing to any object derived from OUTPUTFORMATTER.

> 
> Is there any mileage in making PLUGIN having a stream-based interface
> so that you can feed it any stream? The downside to this is the
> LINE_READER-based plugins are substantially (~10 times) faster for
> actual files than for wxFFileInputStreams (with another ~10x slowdown
> for wxFileInputStream), which would slow down the native file handling
> unless there's some extra handling like:
> 
> * There is a parallel filename interface (as currently), which defers
> to the stream-based implementation unless overridden, or
> * The interested classes check if the stream is a file stream and
> actually use the underlying file using the GetFile() method.

The PLUGIN object is very much designed for handling files on a per
plugin basis.  The files could be on the local file system, Github, or a
compressed archive but they are still files.

> 
> There are more questions about the footprint load too, which is even
> more file-system-centric, as it takes two paths:
> 
>     MODULE* FootprintLoad( const wxString& aLibraryPath, const
> wxString& aFootprintName, const PROPERTIES* aProperties)

The use of attributes aLibraryPath and aFootprintName determined by the
plugin.  They could easily be translated by the plugin for uses other
than a library path or a footprint name.  This all depends on the plugin
itself.

> 
> And then, further for the saving functions, which also can only write
> to the file system.
> 
> TL;DR: Should we look at making board and library functions more
> "generic" in that they don't require actual files on disk?
> 
> Cheers,
> 
> John
> 
> _______________________________________________
> 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
>