It can be difficult for a user to understand how to make a connection between abstract and high-level discussion of how dripline works and practical understanding of how to start operating equipment. In particular, some patterns/features/choices are intrinsic aspects of dripline, while others just happen to be true for the classes that are already implemented. The following documentation additions would hopefully help with this (possibly to be broken out into their own issues depending on when they are worked on):
[ ] Discussion of ethernet support and assumptions. In particular, some discussion of various standard that we at least partly touch. Also the assumptions the existing classes make about what the interactions with a device should look like, and where it may or may not make sense to push those boundaries for other devices.
[ ] Expansion of the "alerts"/"logging" (as in to a database) system. Similar to above for network communication, really focusing on the delineation of things that are true about logging in dripline always vs the things that are true for the classes that are available "out of the box" for use. Also similar, discuss both where small extensions may be valuable and when fully new implementations are probably required. Also include some digression into what a reasonable storage backend may look like (and be clear that it is digression).
[ ] Discussion of how to bolt on fully brute force capabilities and use dripline for more-or-less arbitrary RPC to python-implemented systems. Should note both how powerfully this will let you just get something running but also caution about both fragility and technical debt that come along with doing this.
[ ] Discussion of scripting pattern and recommendation about how to go about adding high-level/complex-logic/synchronous tasking to an existing mesh.
It can be difficult for a user to understand how to make a connection between abstract and high-level discussion of how dripline works and practical understanding of how to start operating equipment. In particular, some patterns/features/choices are intrinsic aspects of dripline, while others just happen to be true for the classes that are already implemented. The following documentation additions would hopefully help with this (possibly to be broken out into their own issues depending on when they are worked on):
[ ] Discussion of ethernet support and assumptions. In particular, some discussion of various standard that we at least partly touch. Also the assumptions the existing classes make about what the interactions with a device should look like, and where it may or may not make sense to push those boundaries for other devices.
[ ] Expansion of the "alerts"/"logging" (as in to a database) system. Similar to above for network communication, really focusing on the delineation of things that are true about logging in dripline always vs the things that are true for the classes that are available "out of the box" for use. Also similar, discuss both where small extensions may be valuable and when fully new implementations are probably required. Also include some digression into what a reasonable storage backend may look like (and be clear that it is digression).
[ ] Discussion of how to bolt on fully brute force capabilities and use dripline for more-or-less arbitrary RPC to python-implemented systems. Should note both how powerfully this will let you just get something running but also caution about both fragility and technical debt that come along with doing this.
[ ] Discussion of scripting pattern and recommendation about how to go about adding high-level/complex-logic/synchronous tasking to an existing mesh.