91 | | |
92 | | + current interfaces to other entities, and message flows (like “AA-workflow”) [[BR]] |
| 91 | Depends on what sort of interfaces we have. The plan is to port the |
| 92 | existing perfAdmin GUI to work with the new configuration in the new |
| 93 | UNIS. If that happens we can do a similar demo to last time as far as |
| 94 | how it looks. All the names of different tools should look a bit more |
| 95 | streamlined since everything is going through blipp, and there is only |
| 96 | one measurement store, but since most of the work has been on |
| 97 | generalizing the backend code, the demo shouldn't change much. |
| 98 | |
| 99 | Now that the configuration structure has mostly settled, we can |
| 100 | start working on interfaces to configure BLiPP. If we aren't able to |
| 101 | port in time, the old tools are still available. It should also be |
| 102 | pretty easy to write a quick client tool that can get and post new |
| 103 | config from and to UNIS. |
| 104 | |
| 105 | + current interfaces to other entities, and message flows (like “AA-workflow”) [[BR]] |
| 106 | BLiPP interacts with UNIS and the MS through their well defined APIs, |
| 107 | it doesn't expose any interface itself, although this might be |
| 108 | something to think about in the future so that it can be commanded to |
| 109 | reload config rather than waiting for it to poll UNIS. See figures above for details. |
| 110 | |
| 111 | Blipp does reload it's config file at the same time it reloads config |
| 112 | from UNIS, so it can be reconfigured that way, but anything that's |
| 113 | already in UNIS will override changes in the file. |