backend: simplify *Request style IPC messages

[silverjam]

We have a bunch of messages that are for various "requests" such as "TCP
connection request", "file open request" and a "pause request".

This removes the ConnectRequest generic type and instead just uses the
main Message type.

[john-michaelburke]

I see you are not a fan of the nesting 😄 . The simplified approach definitely reduces the amount of code.

[silverjam]

I see you are not a fan of the nesting 😄 . The simplified approach definitely reduces the amount of code.

I was wondering if there was a specific technical reason we needed the generic message, but the nesting makes sense from a organizational standpoint too. I noticed that the *Request message are already in the main Message type, so was a little confused by that.

Motivation for removing this was to make porting to other protocol formats in the future easier. I wanted to see if I could try out msgpack/quicktype as an alternative to capnproto.

[john-michaelburke]

I see you are not a fan of the nesting 😄 . The simplified approach definitely reduces the amount of code.

I was wondering if there was a specific technical reason we needed the generic message, but the nesting makes sense from a organizational standpoint too. I noticed that the *Request message are already in the main Message type, so was a little confused by that.

Motivation for removing this was to make porting to other protocol formats in the future easier. I wanted to see if I could try out msgpack/quicktype as an alternative to capnproto.

Fair enough. Are you trying out of other proto alternatives to also see about possibly moving away from python to C++? Or just to compare performance with Capnproto?

[silverjam]

Motivation for removing this was to make porting to other protocol formats in the future easier. I wanted to see if I could try out msgpack/quicktype as an alternative to capnproto.

Fair enough. Are you trying out of other proto alternatives to also see about possibly moving away from python to C++? Or just to compare performance with Capnproto?

It's for trying to move to a web based platform where capnproto support really doesn't exist.