[pdal] DLL plug-ins to PDAL

[Michael P. Gerlek]

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
desired.)

* 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.

-mpg


> -----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
> need?
> 
> Brad,
> 
> 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.
I'll
> give a short synopsis of GDAL's plugin architecture and then provide a
little
> 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
conformed
> to in order to be a Driver. Drivers, consisting of shared objects
(.so/.dylib or
> .dll) placed in a specially-named directory), are loaded at runtime using
the
> 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
directory
> 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
methods
> 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.
Instead
> it has at least three (maybe four) major objects -- Reader, Writer,
Filter,
> MultiFilter. Each has a clean interface that can be conformed to and each
has
> a the ability to be constructed using the generic Options container. We
have
> 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
cleaner
> 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?
I
> 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
we
> 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.
> 
> Thanks,
> 
> Howard
> 
> 
> 
> 
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pdal