Peter Bourgon

Please do! Before starting in with the code properly, I'd suggest doing a design phase, either just as a narrative in this issue or with a bit of pseudocode.

1. I'd expect that users would know the port a priori when specifying a set of EC2 instance tags. Is that reasonable? If you deploy an EC2 AMI, your service...

Neat! So I haven't fully explored this yet, but I think the entire endpoint layer might be able to go away with generics — the transport layer should be able...

> Isn't it more natural to do data validation at the service layer? "Data validation" is an umbrella term that covers both protocol or schema validation — is this a...

The transport layer should not check semantic validity, because semantic validity is a property of, or defined by, or 1-to-1 with, the service itself. Whereas schema and protocol validity is...

> what I was saying is that I'm used to do "syntax" validation (right JSON, protobuf, ...) in transport, "semantic" validation in endpoint and use the "validated data" in the...

> we use transports as per designed . . . at the transport package we use encoders/decoders into service-specific datatypes Sure! This just means your services are tightly coupled to...

I'm keen to see this possible. Unfortunately, I'm not sure how to do it without futzing with package-global state. _edit_: Maybe we could add the SetLevelKey decorator (or something like...

Package global configuration via env var in `init` is a non-starter, sorry.

Ah, interesting, I must have missed that bit. It's clever! I like it. Is it good enough for the users who need it?