Chatting with linkfanel we came to some conclusions:<br><br>Core:<br>1. Per-node (thus, per-client) notification is a no-go. Clients implement ignoring events (for nodes) that they are not interested in.<br><br>2. Per-node children-fetching is cool.<br>
Implementation: item tree belongs to the module. Fetching is a request from a client to fetch children of a specific node. On first request for a node, the module fetches data and fills the node with children, sending out a notification about items inserted. Of course there must be either a valid request to fetch children of null node (= imaginary root node) or separate request to fetch top items.<br>
<br>GUI:<br>3. It's important for a user to see and have quick access to available plugins and to activate / deactivate them. Hence the interface shows a drop-down box with checkable SD plugin items.<br><br>4. Nevertheless, the SD item categorization does not necessarily map to plugins. Items spawned by plugins can be (and shall be) distributed into meaningful categories.<br>
<br>5. It's still an open question whether a GUI stores enabled plugins list and activates all last-enabled plugins already at startup. If we have the beforementioned features of per-node fetching and well-exposed control of plugin activation, then I think this is plausible enough.<br>
<br>Kind regards!<br>