[pdal] DLL plug-ins to PDAL

[Howard Butler]

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