[pdal] DLL plug-ins to PDAL

[Michael P. Gerlek]

OK, yeah, I like the GDAL mechanism -- basically, I think, each driver lives
in a DLL, and the DLL has a PleaseRegisterMe() function which adds it to the
stage factory.  Simple, clean, easy.

-mpg



-----Original Message-----
From: Michael P. Gerlek [mailto:mpg at flaxen.com] 
Sent: Monday, August 29, 2011 8:56 AM
To: 'Howard Butler'; 'Bradley Chambers'
Cc: pdal at lists.osgeo.org
Subject: RE: [pdal] DLL plug-ins to PDAL

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