Is your feature request related to a problem? Please describe.
Each session in the RPC server has its own DB (in-memory SQLite). When sessions are terminated/removed, we have no way of reading the metrics we collected.
Possible solutions:
Not sure of the ideal solution yet, may have to try a few ideas. This is a working PR, input welcome.
idea 1: serve the session DB as structured JSON
Add an RPC method getDb(session_id) that serializes the contents of the DB into JSON.
It may be possible to avoid strict typing (which would make it very cumbersome to update the DB schema) by directly serializing the DB to JSON. Not 100% sure about this, though. If it's not possible to serialize directly, this isn't worth the effort.
idea 2: host an endpoint that serves a .db file download
This is pretty straightforward, but not a very good UX.
Note: Our JSON-RPC server struct holds the sessions, which prevents other servers (e.g. a REST server to serve files) from getting session data. To do this, we'd need to decouple sessions from the RPC server; make a new struct for sessions with a simplified API, then call that from the RPC server. Then other servers could get access to the data as well.
idea 3: host an API to query the DB
We could implement the same kind of things that report does (calculate metrics, format data for human/UI consumption) but we'd need to implement another API for the report functions we want. These are currently implemented directly in the report function.
Another idea is to use something like datasette. This would host an API that allows you to read the DB tables directly, over a web interface, with the option to export data in multiple formats.
It may be worthwhile to use both approaches; datasette for specific DB inquiries, and extra RPC endpoints for simple metrics collection.
Is your feature request related to a problem? Please describe.
Each session in the RPC server has its own DB (in-memory SQLite). When sessions are terminated/removed, we have no way of reading the metrics we collected.
Possible solutions:
Not sure of the ideal solution yet, may have to try a few ideas. This is a working PR, input welcome.
idea 1: serve the session DB as structured JSON
Add an RPC method
getDb(session_id)that serializes the contents of the DB into JSON.It may be possible to avoid strict typing (which would make it very cumbersome to update the DB schema) by directly serializing the DB to JSON. Not 100% sure about this, though. If it's not possible to serialize directly, this isn't worth the effort.
idea 2: host an endpoint that serves a
.dbfile downloadThis is pretty straightforward, but not a very good UX.
Note: Our JSON-RPC server struct holds the sessions, which prevents other servers (e.g. a REST server to serve files) from getting session data. To do this, we'd need to decouple sessions from the RPC server; make a new struct for sessions with a simplified API, then call that from the RPC server. Then other servers could get access to the data as well.
idea 3: host an API to query the DB
We could implement the same kind of things that
reportdoes (calculate metrics, format data for human/UI consumption) but we'd need to implement another API for the report functions we want. These are currently implemented directly in thereportfunction.Another idea is to use something like datasette. This would host an API that allows you to read the DB tables directly, over a web interface, with the option to export data in multiple formats.
It may be worthwhile to use both approaches; datasette for specific DB inquiries, and extra RPC endpoints for simple metrics collection.