Now that we have a 1:1 correspondence between Publishers and OutputStreams in Units, and the ability to set Publisher specifics from the OutputStream initializer, it is now a little unintuitive and surprising that OutputStreams in Collections do not actually result in the creation of a Publisher that we could subscribe to from another process. In particular, if a user has an OutputStream as part of a Collection that they want to expose on a public port (e.g. by defining the host or port keyword arguments for the collection OutputStream) -- currently, no Publisher will be created which is confusing behavior at best (and maybe a bug at worst). The only time Publishers and Subscribers are created are when there is an OutputStream or InputStream defined as part of a Unit.
Adding a "Republisher" Unit at the collection level for each collection OutputStream could alleviate this confusing behavior, but at the expense of occupying more sockets and performance degradation. A Republisher decorator or hint of some sort might allow a user to explicitly define when an OutputStream is republishing a topic could be a beneficial feature addition, as well as a warning when it appears that a user is attempting to interact directly with Collection level Streams. Currently, this is a bigger issue with OutputStreams because Subscriber objects have no configurable keyword arguments, but that's subject to change (future stream type enforcement/message filtering?) so it may be that republishers are required for all collection streams (performance regressions be damned).
Now that we have a 1:1 correspondence between
Publishers andOutputStreams inUnits, and the ability to setPublisherspecifics from theOutputStreaminitializer, it is now a little unintuitive and surprising thatOutputStreams inCollectionsdo not actually result in the creation of aPublisherthat we could subscribe to from another process. In particular, if a user has anOutputStreamas part of aCollectionthat they want to expose on a public port (e.g. by defining thehostorportkeyword arguments for the collectionOutputStream) -- currently, noPublisherwill be created which is confusing behavior at best (and maybe a bug at worst). The only timePublishers andSubscribers are created are when there is anOutputStreamorInputStreamdefined as part of aUnit.Adding a "Republisher"
Unitat the collection level for each collectionOutputStreamcould alleviate this confusing behavior, but at the expense of occupying more sockets and performance degradation. ARepublisherdecorator or hint of some sort might allow a user to explicitly define when anOutputStreamis republishing a topic could be a beneficial feature addition, as well as a warning when it appears that a user is attempting to interact directly withCollectionlevelStreams. Currently, this is a bigger issue withOutputStreamsbecauseSubscriberobjects have no configurable keyword arguments, but that's subject to change (future stream type enforcement/message filtering?) so it may be that republishers are required for all collection streams (performance regressions be damned).