-
Hi Eclipse-DataSpaceCommunity! We are interested in bringing over some of the functionality from our Trusted Connector and IDSCP2 projects (https://github.com/industrial-data-space/trusted-connector, https://github.com/industrial-data-space/idscp2-java) onto this platform. We are also interested how we can contribute to some of the aspects of SSI (see #56). Therefore, we would like to start the discussion about some of the technical guidelines when writing data-protocols and extensions.
We wanted to clarify these basic points before coming up with a plan to contribute (and what to contribute) in more detail. |
Beta Was this translation helpful? Give feedback.
Replies: 0 comments 5 replies
-
Hi We would welcome contributions in any area. Regarding your questions:
I think porting the Trusted Connector to EDC modules would be great, and doing it in Java would be a way to make sure those extensions are integrated with the rest of the EDC community. |
Beta Was this translation helpful? Give feedback.
-
Maybe another thought on this. @jimmarino Would it be possible / is it planned to publish jar artifacts of the EDSC on GH or maven central, so others can use it to base their connector implementation on. Currently, we use SpringBoot in the Trusted Connector, but this was mostly because of the fact the the IDSA-DSC was using it and we wanted to be more compatible. If now things move towards the EDSC, we could think about switching the underlying "framework" from SpringBoot to the EDSC framework, basically keeping our code in an separate repo and creating our extensions in Kotlin (at least for now). Just thinking out loud here. cc @gbrost |
Beta Was this translation helpful? Give feedback.
Hi
We would welcome contributions in any area.
Regarding your questions:
Our idea is to restrict core dependencies and commonly used extensions but allow more leeway in other extensions. Overall, however, we would like to minimize dependencies for modules in this repo since the build dependency tree has to remain manageable as the number of extensions grows. Unfortunately, some cloud providers (e.g. the AWS and MSAL libraries) contain a boatload of dependencies. I don't think we can do much with the AWS libraries, but we should see if we can eliminate the use of MSAL.
For Kotlin, I would start by saying that the existing code from the Trusted Connector will likely have to be significa…