The net_module config option already offers clients a great deal of flexibility, but its API is brittle due to tight coupling and it’s difficult to extend its capabilities beyond what is offered now. Even within those limits, you often end up having to duplicate lots of existing code. A more generic plug-in API would help resolve these issues. It could be added in the following steps:
Document the design of the plug-in API itself. ✅ – see Plugin.pm
Implement the plug-in API far enough to make the net_module option redundant. ✅
Convert test suite, simulator etc. to plug-ins. ✅
Update the documentation across the driver to refer to plug-ins instead of the net_module option. Also update Neo4j::Driver::Net as required, including how to convert existing code to plug-ins. ✅
Remove or deprecate the net_module option. ✅
That’s how far this PR is intended to take it. Probably also good enough for the eventual release of version 1.00 of the driver. Past that, the following “stretch goals” are conceivable:
Offer a few selected additional events for plug-ins to hook into. There are some obvious low-hanging fruits that can vastly extend the driver’s flexibility. For example, an event triggered during URI parsing could be used to implement support for the neo4j: URI scheme in a plug-in. Events during the deep_bless operation in the result handlers could be used to modify the result format to your needs. Also, exception events could make proper error handling easier (related to #7).
In the long run, it might perhaps be nice to offer events not just whereever they're easy to add in an opportunistic fashion, but to have a complete set of events triggered at strategic points throughout the driver. Ideally, all parts of the software’s implementation should be swappable or controllable through plug-ins. In fact, many if not most parts of the driver itself theoretically could be implemented as individual plug-ins. This would however likely require a quite careful redesign of the driver, and I’m thinking YAGNI. (But do tell me if you feel this would be useful.)
The entire plug-in API is to be considered experimental until further notice (as noted in the docs).
The
net_moduleconfig option already offers clients a great deal of flexibility, but its API is brittle due to tight coupling and it’s difficult to extend its capabilities beyond what is offered now. Even within those limits, you often end up having to duplicate lots of existing code. A more generic plug-in API would help resolve these issues. It could be added in the following steps:net_moduleoption redundant. ✅net_moduleoption. Also update Neo4j::Driver::Net as required, including how to convert existing code to plug-ins. ✅net_moduleoption. ✅That’s how far this PR is intended to take it. Probably also good enough for the eventual release of version 1.00 of the driver. Past that, the following “stretch goals” are conceivable:
Offer a few selected additional events for plug-ins to hook into. There are some obvious low-hanging fruits that can vastly extend the driver’s flexibility. For example, an event triggered during URI parsing could be used to implement support for the
neo4j:URI scheme in a plug-in. Events during thedeep_blessoperation in the result handlers could be used to modify the result format to your needs. Also, exception events could make proper error handling easier (related to #7).In the long run, it might perhaps be nice to offer events not just whereever they're easy to add in an opportunistic fashion, but to have a complete set of events triggered at strategic points throughout the driver. Ideally, all parts of the software’s implementation should be swappable or controllable through plug-ins. In fact, many if not most parts of the driver itself theoretically could be implemented as individual plug-ins. This would however likely require a quite careful redesign of the driver, and I’m thinking YAGNI. (But do tell me if you feel this would be useful.)
The entire plug-in API is to be considered experimental until further notice (as noted in the docs).