You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 21, 2019. It is now read-only.
-> @olligobber#6 will look into the Protocol Specification using session types and other techniques so that the end user or us can provide a generic set of protocol specifications that Overwatch may use to do its packet analysis. I think this research into session types may also turn out to be a way to formalise @CMCDragonkai's ideas about automaton composition in #9. Will also continue to work on all the related monitoring/proiling techniques in Overwatch as he works on the specification.
-> @mokuki082#8 will work on the Artifact specification in Architect and continue to work on the docker bindings in haskell, and associated configuration to do with virtual networks. The end goal here I think is to produce a unified interface that allows us to bring up the artifact on the local machine and network them virtually as required, through a single interface (and encode any details about the Artifact as necessary in Automaton as above). I'll be working in this area to integrate the interface with substituting the automaton names/content hashes listed in the dependencies inside the artefact, with the correct IP once the virtual network link has been established.
-> @Kneedler#11 I'll continue to explore the Dependency specification design, along with @CMCDragonkai's ideas about what it means to combine/compose an automaton (literally the possible ways we can classify different sets of interactions between two or more automatons), looking at if/how we can do dependency injection and live garbage collection of dependencies. I'll also work with @olligobber in this department to make sure that whatever model we choose for modelling dependencies between automatons integrates with the monitoring system information we can get from Overwatch (so that we have a path to automatically deploying automatons in some optimal configuration based on the monitoring system information).
The text was updated successfully, but these errors were encountered:
@Kneedler Can you figure out what are the implications of hash collisions on a distributed system? Like ours since we are going to have hashes pointing to Automatons and its friends.
Looking at what we have so far for the automaton spec from #3 :
-> @olligobber #6 will look into the Protocol Specification using session types and other techniques so that the end user or us can provide a generic set of protocol specifications that Overwatch may use to do its packet analysis. I think this research into session types may also turn out to be a way to formalise @CMCDragonkai's ideas about automaton composition in #9. Will also continue to work on all the related monitoring/proiling techniques in Overwatch as he works on the specification.
-> @mokuki082 #8 will work on the Artifact specification in Architect and continue to work on the docker bindings in haskell, and associated configuration to do with virtual networks. The end goal here I think is to produce a unified interface that allows us to bring up the artifact on the local machine and network them virtually as required, through a single interface (and encode any details about the Artifact as necessary in Automaton as above). I'll be working in this area to integrate the interface with substituting the automaton names/content hashes listed in the dependencies inside the artefact, with the correct IP once the virtual network link has been established.
-> @Kneedler #11 I'll continue to explore the Dependency specification design, along with @CMCDragonkai's ideas about what it means to combine/compose an automaton (literally the possible ways we can classify different sets of interactions between two or more automatons), looking at if/how we can do dependency injection and live garbage collection of dependencies. I'll also work with @olligobber in this department to make sure that whatever model we choose for modelling dependencies between automatons integrates with the monitoring system information we can get from Overwatch (so that we have a path to automatically deploying automatons in some optimal configuration based on the monitoring system information).
The text was updated successfully, but these errors were encountered: