[pdal] DLL plug-ins to PDAL
Michael P. Gerlek
mpg at flaxen.com
Mon Aug 29 11:56:01 EDT 2011
I've had a possible customer express interest in dynamic loading too, so
this is definitely something we should be plumbing in.
A couple additions to Howard's comments:
* Actually StageBase is the root class these days -- Writer and Stage both
derive from StageBase, and Reader/Filter/MultiFilter derive in turn from
Stage. (StageBase isn't a very inspired name, I know. Happy to change if
* I might suggest using subdirs for naming -- that is, instead of
<dll_dir>/PDAL_LasReader_Reader.dll, maybe <dll_dir>/readers/LasReader.dll
-- I dunno why, but this seems a little prettier to me.
* StageFactory is the class that knows how to instantiate a driver when
given the driver name (like "drivers.readers.las"). It is what is used by
PipelineManager, and it knows about all the "built-in" driver classes, and I
added a function to allow you to add a new driver on the fly -- you give it
the driver name and a pointer to a "creator" function.
* Knowledge of the mapping from filename extension to reader/writer driver
type is currently out at the app level (in AppSupport), but it might be nice
to put this into StageFactory too. Or maybe each reader/writer driver
should have a static function listing the extensions it thinks it knows
about. (But note I'm not in favor of putting an automatic file-opener
system in the core library; that really belongs in AppSupport.)
* StageFactory is not a singleton, but maybe arguably should be.
I'm going to go look at GDAL's code, more as I think of it.
> -----Original Message-----
> From: pdal-bounces at lists.osgeo.org [mailto:pdal-bounces at lists.osgeo.org]
> On Behalf Of Howard Butler
> Sent: Monday, August 29, 2011 7:02 AM
> To: Bradley Chambers
> Cc: pdal at lists.osgeo.org
> Subject: Re: [pdal] DLL plug-ins to PDAL
> On Aug 29, 2011, at 7:26 AM, Bradley Chambers wrote:
> > All,
> > I work with a group that was asked to develop a driver for PDAL that
> > is proprietary. And so the question comes up, how to best manage these
> > going forward. In a few offline discussions with Hobu, we've discussed
> > the need for PDAL to potentially support such drivers via a DLL
> > plug-in interface.
> > I'd be interested to hear the groups' thoughts. Do others have a similar
> Yes we need plugins. It's one of the things that has made GDAL very
> successful, and PDAL's design is such that it should be straightforward.
> give a short synopsis of GDAL's plugin architecture and then provide a
> bit of partially coalesced thoughts on how we can implement it in PDAL.
> GDAL's plugin architecture is made possible by GDAL's driver architecture.
> Each driver has an interface with a set of functions that must be
> to in order to be a Driver. Drivers, consisting of shared objects
> .dll) placed in a specially-named directory), are loaded at runtime using
> DriverRegistrar's AutoLoadDrivers method. When the caller issues the
> GDAL_RegisterAll() method, these drivers are then loaded. They are
> unloaded using the CleanupAll() method.
> The AutoLoadDrivers method walks each file in the specially named
> that conforms to the gdal_DriverName.dll naming convention. The
> DriverName part of the file name must exactly match the name of the driver
> to be loaded. When found, gdal_DriverName.dll has a symbol in it called
> GDALRegister_DriverName that is called. This method does things like check
> for ABI compatibility, create a new Driver instance, set callbacks for
> that match the driver interface, and place it in the DriverRegistrar.
> PDAL doesn't have the concept of a do-it-all driver for one datatype.
> it has at least three (maybe four) major objects -- Reader, Writer,
> MultiFilter. Each has a clean interface that can be conformed to and each
> a the ability to be constructed using the generic Options container. We
> the PipelineManager that can be used to generate pipelines with these
> objects once they are available to be instantiated (registered).
> This brings up a question about registration -- Writer currently does not
> derive from Stage. Would our registerable drivers all be simply Stage
> instances with an expected constructor that takes in an Options reference?
> Or would we have to register PDAL_DriverName_Type.dll, with type being
> Filter, MultiFilter, Reader, or Writer? I guess I'd like to go for the
> Stage derivation to make the registration machinery simpler. Or maybe a
> class above Stage that is simply a Driver (or some such name)...
> Another issue is what to do with plugin Stages after they're registered?
> suppose we could have to have some sort of singleton Manager object to
> clean these things up when we tear down. PipelineManager could then ask
> this singleton if it has any stages that matches the given name(s). Should
> just register all available Stages to this Manager as well for simplicity?
> I'd be interested to hear your thoughts, Michael, if you have a moment.
> pdal mailing list
> pdal at lists.osgeo.org
More information about the pdal