Olaf Buddenhagen

@vvuk and you consider that a problem?...

Well, there is little we can do about large sends being blocking; so the ambiguity is only in whether the API officially promises small sends below some arbitrary limit to...

@emilio I can't reproduce it either. How exactly does it fail for you?

Sends on the main channel are atomic. When sending large messages that need fragmentation, a dedicated channel is created for that message. (See https://github.com/servo/ipc-channel/commit/ce7c296a3717b054060889b780f8638eb66ce970 for when this approach was originally...

OK, so here's the deal: every time I take a stab at reviewing this, I get stuck trying to figure out what you are attempting to do here... Most notably,...

It seems your `SameSerializationAs` is what I meant with `SameSerialization`, and your `CanonicalSeralization` is what I meant with `SerializesAs`... Though your naming is probably clearer :-) AIUI, the overlap problem...

Hrm, I dropped the ball again... You are suggesting to allow a `channel` itself to be instanced with different (compatible) `Sender` vs. `Receiver` types; and at the same time to...

I guess another follow-up would have been in order?... @asajeffrey the latest signature you proposed for `transmogrify()` seems to be exactly what I had in mind :-) I still think...

@nox note that mere in-place deserialisation is not exactly the same as the Cap'n Proto approach of working with serialised types directly. It's a less radical departure from the Serde/bincode...

I think the actual problem is that for some reason deriving Debug on something with `PhantomData` requires `T:Debug`? Not sure why it does though -- doesn't make sense to me...