Add ability for DSO extension to support new dataset type handling methods

[shaun-a-johnson]

The current methods for providing dataset types (eg: source data formats) for rbldnsd is largely limited to modifying the core code at time of compile. The original concept of providing support for DSO extensions allowed one to 'initialize' a DSO through an external shared object, and theoretically define 'hook' functions that are called at varying points in dataset processing.

This modification extends what the DSO extensions are capable of by adding an embedded dataset type for 'extensions', and supplying a framework of extension functions that can be defined within said extension for the purposes of providing a new dataset type format / data source.

[ammammita]

Hello Shaun, thanks for the brilliant work and the efforts into this and for you patience.

Let me start by saying that i like the patch, i fully understand the purpose of it and that this, or something very similar, should be merged.

I would kindly ask you if you could add to the patch a very small example of a. skeleton of a dynamic loadable module that could be used to write an extension.

I would also like you to add some tests to the test suite. Currently the tests are written for python2.7 and i' almost have the fixes to support python 3.X.

One more question: i've seen that you've added the ds_loaddatasetfn_t prototype and i'd like to understand what's its purpose and what's the need of adding it and why it is necessary. From my limited point ofview, i think it is redundant and the old functions in struct dstype should be enough for every need. But maybe i'm wrong.

Care to explain ?

[rfc1036]

I do not think that this patch should be merged, because its purpose is to help companies that want to develop proprietary dataset types and do not want to publish their source code. This would remove a strong incentive to share improvements to rbldnsd with the community.

BTW, rbldnsd is GPL'ed: even if proprietary code is moved to a DSO it would be very hard to not consider that a derivative work of rbldnsd, considering the design of this patch. This means that distribution of rbldnsd+proprietary DSO would be a violation of its license.

[ammammita]

@shaun-a-johnson in your code struct dsdata has a dataset_file that i hardly see how it can be valued. It's not used in the code and such value is not passed to anything in your code. That's a zombie value.

Also, i don't understand how each "extended" dataset would preserve it's own state (normally done using struct dsdata) if such structure is not extended beyond the stub/proxy implementation that you provided.

This looks like you have somewhing working on your side, then you stripped it down in order to submit the patch but you removed too much of the code.

I think i'm going to reject the patch unless you also provide a working example of how it should work.