Comment 8 for bug 1420403

I'll get someone to work on this tomorrow, if that's OK. For now a few responses to the points in #6 in reverse order:

[2.2] Ports are *no longer* on the unit document (the field is there, but it's not populated anymore). Instead, they are in a separate collection "openedPorts". So opening and closing ports on a unit or a machine won't trigger a change to be reported by the watcher (MachineInfo or UnitInfo are not changed). Let me make it clear this is *by design*, not a bug. For me this means we need to communicate such architectural changes between the GUI and Core teams early and think of the implications.

[2.1] In addition to that above, returning a nil or empty slice to signify no entries is very common and idiomatic in Go and is never causing issues when trying to iterate over it. However, since the wire-format of the API is JSON, null and. [] are neither handled the same way, nor expected to mean the same thing. I suspect there are similar lurking API issues stemming from the assumption that Go's way of handling serialization/deserialization (JSON or otherwise) will work for non-Go clients of the serializated data.

Now, how we can solve these for this issue, but both of them require closer sync up across Juju API and its users to prevent them from happening in the future.

For [2.1], it's easy to ensure both Ports and PortRanges slices of UnitInfo are empty slices when they have a length of 0.
To properly fix [2.2] though, we need to extend the megawatcher to report changes to openedPorts collection, like Francesco suggests.