NASA-AMMOS
MCT Adaptation Dictionary issues <Cubesat issues>
- Dictionary should be organizer. Current dictionary is a flat list, which cases performance and UI issues if you have large numbers of channels in MCT (10k+ typically)
- Plugin for dictionary should be extensible and able to add more sources by config. IE for some cubesats you'll have cubesat dictionary 1, cubesat dictionary 2, cubesat ancillary data (ground station etc) 1, cubesat ancillary data 2.
@mudinthewater's suggestion is a good one, it's better both for users and for performance to have the dictionary organized into folders. Also, instead of loading the entire dictionary up front, you could use a composition provider to lazy-load the tree. This will mean that the dictionary is progressively loaded only when requested (for example by expanding a folder). This would require support on the server side for progressively serving the dictionary in response to requests. This could be a web service driven by a database, or it could be separate JSON files per subsystem, for example. It depends somewhat on how you choose to reorganize the dictionary, and on how AIT stores its dictionary.
We have implemented virtual scrolling of the object tree in Open MCT which goes some way toward improving performance in the tree by only loading as many DOM nodes as are needed to render the dictionary items that are currently scrolled into view. This doesn't get around the fundamental problem of keeping a very large data structure representing the dictionary in memory though. Reorganization and lazy-loading should solve that though.
@akhenry please tell me they're not trying to punt their adaptation issues to the MCT team rather than fix their broken adaptation
Dev update: With changes associated with this issue, AIT Integration is now making better use of the Composition provider to organize packets as folders, each containing a set of telemetry fields.
Also introduced option to include packet in the field name:
