> As somebody who is actually writing and reviewing a lot of charms,
> it isn't realistic to expect every charm to implement every interface
> that we come up with immediately.
That's a straw man argument. There's nothing indicating someone should do this in this thread.
> Knowing the charm + ports will enable exactly that, and more emergent behavior
No, it won't. You can't monitor a port without knowing what protocol is being spoken on it. A charm can't assume it knows what another author is doing with the ports on her own charms. open-port is not what this whole thread makes it look like.
(...)
> You're basically saying to do that, I have to add a provides: relationship
> with exactly the same information as open-port would provide, on every
> single service.
Another straw man. I'm not saying that. I'm saying that to communicate between charms, you need to use a relation, because that's the proper way to do that in juju. It's as simple as that. open-port means something else.
> As somebody who is actually writing and reviewing a lot of charms,
> it isn't realistic to expect every charm to implement every interface
> that we come up with immediately.
That's a straw man argument. There's nothing indicating someone should do this in this thread.
> Knowing the charm + ports will enable exactly that, and more emergent behavior
No, it won't. You can't monitor a port without knowing what protocol is being spoken on it. A charm can't assume it knows what another author is doing with the ports on her own charms. open-port is not what this whole thread makes it look like.
(...)
> You're basically saying to do that, I have to add a provides: relationship
> with exactly the same information as open-port would provide, on every
> single service.
Another straw man. I'm not saying that. I'm saying that to communicate between charms, you need to use a relation, because that's the proper way to do that in juju. It's as simple as that. open-port means something else.