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
Currently, to directly get archived recordings/labels from cryostat's file system, users have to supply a subdirectoryName, and a recordingName to either get/post/delete the report/recording/labels/grafana-report/ etc. depending on the request.
In the archives view, the web-client requests for an archivedDirectories get response returns the archives directory structure including the jvmId for each target subdirectory name, instead of the actual subdirectory name (which is just the base32 encoding of the jvmId in UTF_8 standard encoding), and the recordings in each target, and populates a table with this data.
This means that to do actions using this view, we need to supply a subdirectory name to the request, but since the web-client only knows about each target's jvmId, we currently use a util function to base32 encode the jvmId in the web-client itself and then send it over.
Instead of this extra encoding/decoding logic on both client and server, it is probably better to have all conversion processing on the server side, and only require jvmIds to be passed in and out of requests and responses to the cryostat backend, which means a little refactoring for each "fromPath" method handler.
The text was updated successfully, but these errors were encountered:
Currently, to directly get archived recordings/labels from cryostat's file system, users have to supply a subdirectoryName, and a recordingName to either get/post/delete the report/recording/labels/grafana-report/ etc. depending on the request.
In the archives view, the web-client requests for an archivedDirectories get response returns the archives directory structure including the jvmId for each target subdirectory name, instead of the actual subdirectory name (which is just the base32 encoding of the jvmId in UTF_8 standard encoding), and the recordings in each target, and populates a table with this data.
This means that to do actions using this view, we need to supply a subdirectory name to the request, but since the web-client only knows about each target's jvmId, we currently use a util function to base32 encode the jvmId in the web-client itself and then send it over.
Instead of this extra encoding/decoding logic on both client and server, it is probably better to have all conversion processing on the server side, and only require jvmIds to be passed in and out of requests and responses to the cryostat backend, which means a little refactoring for each "fromPath" method handler.
The text was updated successfully, but these errors were encountered: