Feature: generic serializers about tarpc HOT 4 CLOSED

tarpc::Error would either need to become generic over two error types, application and serialization errors, or we could just make the serialize error variant store a string Box<std::error::Error>. Would that be awful?

Another option would be to just treat all deserialize errors as permanent/non-retryable -- they probably represent application errors anyway. It'd also be symmetrical with serialize errors?

from tarpc.

How about an even wilder idea: generic transport? Imagine using tarpc codegen to build HTTP REST services, emulating the functionality of Jersey and Feign.

That would mean, of course, building some equivalent of JAX-RS annotations, which is another can of worms...

from tarpc.

I think that's covered by #38. A long time ago, when I first started tarpc, the transport actually was generic. But I felt usability suffered. Could be worth revisiting if the landscape is different now!

from tarpc.

Obsoleted by #199.

from tarpc.