[pdal] DLL plug-ins to PDAL
Michael P. Gerlek
mpg at flaxen.com
Mon Aug 29 13:54:05 EDT 2011
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
More information about the pdal
mailing list