refactor: remove connection protocol

hyperledger / aries-cloudagent-python

Hyperledger Aries Cloud Agent Python (ACA-Py) is a foundation for building decentralized identity applications and services running in non-mobile environments.

https://wiki.hyperledger.org/display/aries

Apache License 2.0

405 stars 510 forks source link

refactor: remove connection protocol #3184

Open dbluhm opened 1 month ago

dbluhm commented 1 month ago

This PR Removes the deprecated connections protocol.

In addition to the message handlers and routes, this also means:

CLI flags relating to connections protocol removed.
References to specific messages in base connection manager were removed; there will need to be some working around this in the plugin to continue to support the protocol but I think it's good and necessary to at least rip it out for now here.
Introduction protocol used to use Connections invitations. I did a very rough-and-ready conversion to OOB invites.
Connections management routes (e.g. querying connections) were moved to aries_cloudagent.connections.routes (from aries_cloudagent.protocols.connections.v1_0.routes).

I am expecting this to not be fully functional yet so opening as a draft for now.

PatStLouis commented 1 month ago

@dbluhm it was mentioned on the call this was moved to a plugin. Is the code to enable using that plugin included in this pr?

swcurran commented 1 month ago

It’s in the plugin repo: https://github.com/hyperledger/aries-acapy-plugins/pull/925

PatStLouis commented 1 month ago

@swcurran thank you, I was referring towards the "code required to make this plugin work" which was highlighted in the meeting.

The functionality lost/broken features outlined here, will this require code from within the aca-py code base or it can all be managed in the external plugin?

swcurran commented 1 month ago

Doh…sorry about that. Good point. And per my comment in the meeting — is it viable to simply document how to use the plugin? I suppose not being able to use the artifacts directly (e.g., having to change the Python code) might be a bit too painful.

dbluhm commented 1 week ago

With the most recent updates on this branch and to the corresponding plugin, I have successfully completed a connection using the plugged in connection protocol. There are some failing tests I will address but I will go ahead and mark this as ready for review.

sonarcloud[bot] commented 4 days ago

Quality Gate failed

Failed conditions
52.8% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

swcurran commented 4 days ago

Cool. Let’s include in our discussion tomorrow the version number if we remove this. 1.1.0?

Should the SonarCloud analysis be addressed before merging?

dbluhm commented 4 days ago

I'm just wondering if maybe a scenario test that installs the plugin and creates a v1 connection might be a good idea.

We can do that though this is basically what's happening in the integration test of the plugin itself. So I'm not sure how valuable it is for it to be tested in both places.

We'll need good docs for when it gets released.

Indeed, I have not adequately addressed this need yet.

Should the SonarCloud analysis be addressed before merging?

I am not too concerned personally. The most complaints are coming from code that was just moved but detected as new in the connection routes (moved from the protocols.connections.routes to connections.routes).