Connection protocol as a plugin?

[dbluhm]

trafficstars

This might be a crazy idea but what if we moved the old connection protocol code out into a plugin?

As it stands, with recent fixes and updates, the protocol itself is more cleanly isolated from the code base than ever before.

I see at least a couple of benefits to this:

• We can, for the most part, stop worrying about continued development and maintenance of the connections protocol.
• As a separate plugin, if someone wants to change something, that can be handled independent of ACA-Py.
• Deployments that still depend on connections can pull the plugin in.
• We continue to drive the community forward to bigger and better things.

If this is successful, we could use the same strategy for future deprecated protocols. This approach would prevent ACA-Py from continuously growing in size. Additionally, it would allow old protocols to phase out more naturally, rather than keeping them on life support longer than necessary.

Thoughts?

@swcurran @ianco @usingtechnology @andrewwhitehead

[swcurran]

Sounds like a good approach to me. Those not using it have no change. Those using it need to change the startup configuration to pull in the plugin and settings. Breaking change with instructions in the Changelog to publish the deprecation/removal.

[dbluhm]

To further clarify my thoughts, I would recommend moving the plugin code out of the ACA-Py repo. This would mean that there would be a little more than just a minor configuration change for those using connections still but it shouldn't be anything too bad. A two line Dockerfile would probably suffice.

[swcurran]

I assume this does get us to needing an “aries-acapy-plugins” repo — or we have a proliferation of single use repos. Correct?

[dbluhm]

Yes, indeed, I agree that the right place for this would probably be a plugins (plural) repo. This would serve as a destination for other future deprecated protocols, too, in addition to the other benefits we've previously discussed about having such a repo.

[usingtechnology]

So there was this PoC for plugins that never really took off (was hoping traction would port over their common plugins). I like the idea of trimming the code down to the core and using plugins. We do have @ianco work on potential future paths for plugins that is worth looking at again if we are about to make a first "official" plugin.

Traction (AFAIK) does use the connection protocol (not exclusively)... but since they are using many plugins, perhaps th3ey can contribute some others AND be a nice working example for building out an ACA-Py image and pulling in plugins.