Iced: Clean way of using splitted/shared streams with subscriptions

[fwcd]

When dealing with streams such as WebSockets, it is often useful to have both a sender and a receiver, where only the receiver serves as a subscription and the sender is stored externally (e.g. in the structure implementing the Application).

I have, however, not found a way to cleanly express this concept using the recipe/subscription mechanism, since, as far as I can tell:

• A recipe should be "passive" (e.g. only a URL), hashable (to allow being identified by the runtime) and able to spawn an owned stream
• A subscription should be created from a recipe (since this allows the recipe to internally track which recipes have changed, e.g. by its hash)

This, however, makes it hard to _externally_ spawn a splitted/shared stream (such as a WebSocket) and pass it into a subscription. I have tried implementing Recipe as a wrapper around the actual stream, but this violates the assumption that recipes are "passive" and causes some other subtle issues, e.g. since Application.subscription takes an immutable receiver.

Does the framework have some way of expressing this?

[hecrj]

Why do you need to _externally_ create the stream? I believe the receiver should be created close to its owner, instead of the senders.

In other words, I would create the channel in Recipe::stream, hold the Receiver, and then send a Sender in the first message of the stream.

[fwcd]

Neat idea, thank you!