Adds destructors to cleanup unreferenced capabilities
When the python object associated with a given capability is garbage collected (i.e. there are no more references to it), the object will call capnet to delete the associated capability. Except for flows. Often times, flows should persist, even after python-level references are lost. They must be manually managed.
Wow, this one slipped by me. Is this really the right behavior? What about workflow agent disconnects?
What about workflow agent disconnects?
This is a case I didn't consider. I'm not sure about that. I think it's definitely not correct to make the user manually garbage-collect their capabilities. A) because we use a lot of capabilities in the workflows, and B) because it's just a very un-python interface.
Maybe there's a way to preserve this behavior without killing all capabilities when the agent disconnects? Seems kinda gross, so I'm not sure.
For now, I'd be happy to resolve it by simply passing a
Protocol()that would expose config bits. Then this auto-delete style could remain the default; but it could be disabled if necessary. Obviously right now there can only be one
Protocol()per port, but if we ever had a different
Transportyou could imagine more than one instance.