Deprecation of vSwarm-proto

[dhschall]

Hey, I want to propose deprecating the vSwarm-proto repo and moving all its functionality into vSwarm.

The reason for this it's always a bit of a mess to make modifications.
For example. If you want to update, fix a bug or add a feature for the relay, you need to make them in the proto repo. Then create a new version. --> Go back to vSwarm update everything to the latest versions.
Furthermore, the only other repo that requires vSwarm-proto is vSwarm-u. This can easily be solved by importing the grpcclients from vSwarm instead vSwarm-proto.

I think, overall this will make development and maintenance easier. Maybe not perfect bu

However, I think I never understand entirely why it needs to be separated so I could be wrong.
@harshitgarg22 can you maybe clarify why it necessary?

[harshitgarg22]

Thanks for pinging.
So I went back through the code and from what I remember, the reason we added this new repo was the following:
If we didn't use a separate repo for the proto files, then in the Dockerfile for relay you would be copying files locally. On adding a new benchmark, you would need to update the Dockerfile for relay every time for these new files to be copied, and then the relay docker image would need to be updated, for no obvious change to relay.
This meant that sometimes a broken image got uploaded, which broke relay for everyone even though no change was made for other benchmarks.

In my mind it was a "separation of concerns", so to speak. :) (Also see: https://stackoverflow.com/a/60465524)

For the issues you mentioned,

1. For vSwarm-u, I think it might lead to more maintenance work if you add the protos back to vSwarm. Because then you would need to update the benchmark's proto version in go.mod for any change to vSwarm (at the time go was introducing go.work which meant that the version of a reference would need to be same for all submodules, not sure if that is still the case). This might break things even if some broken changes are made, unrelated to respective benchmarks.

2. For updating vSwarm for changes to relay in vSwarm-proto. I don't follow this entirely but do you mean changes to the aes_client.go and such (judging from the recent commits)? For this you would only need to make updates to the relevant benchmarks right? For offline testing, instead of updating the URL every time you can try a local reference (I think go.work file allows you to do this, in a way that the changes are kept local and in the remote github repo, the URL of vSwarm-proto is used).

[dhschall]

Ok thank you very much @harshitgarg22 for the clarification. That sounds very reasonable.
Yeah, maybe then its the best to keep it as it is for now and see how it evolves.

And regarding 2. yes developing is not that problematic. I do it usually by having both repos next to each other and replacing the URL of vSwarm-proto but Ill check how the go.work file works