-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dismantle core node framework #57
Comments
A note on the node information interfaces: it seems that they are unnecessary. For the swarm clients they totally make sense -- you have internal classes that do magic stuff which should absolutely not be exposed to the user, but you want to present the user an interface to the classes with purely non-destructive methods. In the case of the swarm nodes, however, there is no "user" to protect from scary internals. It seems like these interfaces should just be removed; they serve no purpose and just make things more complicated. |
Actually, they do serve a purpose: the actual node base classes are templated, so accessing the node via one of these information interfaces saves having to store templated references all over the place. |
Include built-in stats logging. Part of sociomantic-tsunami#57.
Include built-in stats logging. Part of sociomantic-tsunami#57.
Include built-in stats logging. Part of sociomantic-tsunami#57.
The node framework in swarm.core provides many useful components for building nodes. Currently, they are all glued together in a very rigid way. There is essentially one class (
ChannelsNodeBase
) which all nodes must derive from, in order to be able to access the full range of features. As the different types of nodes diverge in their needs, however, this approach is becoming less useful. A nicer approach would be to separate out each of the components so that they can be assembled as required.Components:
INodeInfo
andIChannelsNodeInfo
).It's interesting that the majority of the really interconnected stuff is for stats tracking / logging. Probably a better approach would be to have separate stats instances for different things (per-request, global I/O, etc), each with a
log()
method.The text was updated successfully, but these errors were encountered: