Idemix MSP Folder Structure incompatible with what Fabric expects about fabric-ca HOT 7 OPEN

Why was this change reverted?

from fabric-ca.

Why was this change reverted?

It broke the Java client SDK.

from fabric-ca.

Is anyone using the Idemix provided by Java client SDK's ? If no, I would suggest to drop it. No one is going to keep supporting that implementation.

from fabric-ca.

Yes, people are using it. We already encourage people to use the Fabric Gateway client API instead of the legacy Java SDK, and plan to deprecate the legacy Java SDK once Fabric v2.5 LTS is released. Certainly for Fabric v3 we can break compatibility with the v2.x Idemix implementation.

Producing a new release (v2) of the CA without support for the old style Idemix to go along with Fabric v3 sounds perfectly reasonable. Breaking compatibility with existing client applications or removing capability in a patch release (or even a minor version release) does not seem reasonable.

from fabric-ca.

But Gateway does not support Idemix yet, how are people using idemix moving there?

from fabric-ca.

The identity credentials and signing implementation are pluggable in the Fabric Gateway client API. Anyone could use the Idemix implementation from the legacy Java SDK with the new client API. I suspect nobody has done that - certainly not that I've seen - and there is currently no Idemix signing implementation provided out-of-the-box with the Fabric Gateway client API so I don't think anyone is using Idemix with that client API.

I really don't understand how that impacts whether it's OK to make breaking changes to the CA in patch releases.

from fabric-ca.

I pointed to that because there is no reason to consider this a breaking change if what gets broken should not be there anyway :)

from fabric-ca.