Started 27 days ago
Took 7 min 53 sec
on simtester
Started by timer | |
This run spent:
| |
| Revision: 1f36c9c28a5b4f60740506534e02980f8ac9c70d
Repository: https://gerrit.osmocom.org/pysim
|
Started by timer | |
This run spent:
| |
| Revision: 1f36c9c28a5b4f60740506534e02980f8ac9c70d
Repository: https://gerrit.osmocom.org/pysim
|
esim/http_json_api: add missing check The line actual_sec = func_ex_status.get('statusCodeData', None) suggests that 'statusCodeData' may be None under normal circumstances. So let's guard sec.update(actual_sec) so that we won't run into an exception in case 'statusCodeData' is not in func_ex_status. Related: SYS#7825 Change-Id: I8a1a3cd5e029dba4a3aec1a64702e19b0d694ae2 esim/http_json_api: extend JSON API with server functionality At the moment http_json_api only supports the client role. Let's also add support for the server role. This patch refactors the existing client code. This in particular means that the following preperations have to be made: - To use the existing JsonHttpApiFunction definitions in the client and server the scheme has to be symetric. It already is for the most part, but it treads the header field differently. So let's just treat the header field like any other mandatory field and add it input_params. (this does not affect the es9p.py code since in ES9+ the requests have no header messages, see also SGP.22, section 6.5.1.1) - The JsonHttpApiFunction class currently also has the code to perform the client requests. Let's seperate that code in a JsonHttpApiClient class to which we pass an JsonHttpApiFunction object. - The code that does the encoding and decoding in the client role has lots of conditions the treat the header differently. Let's do the decisions about the header in the JsonHttpApiClient. The encoder and decoder function should do the generic encoding and decoding only. (however, some generic header specific conditions will remain). The code for the server role logically mirrors the code for the client role. We add a JsonHttpApiServer class that can be used to create API endpoints. The API user has to pass in a call_handler through which the application logic is defined. Above that we add an Es2pApiServer class in es2p. In this class we implement the logic that runs the HTTP server and receives the requests. The Es2pApiServer supports all ES2+ functions defined by GSMA SGP.22. The user may use the provided Es2pApiServerHandler base class to define the application logic for each ES2+ function. Related: SYS#7825 Change-Id: I277aa90fddb5171c4bf6c3436259aa371d30d092 contrib: add utility to receive ES2+handleDownloadProgressInfo calls We already have a tool to work with the ES2+ API provided by an SMDP+ (es2p_client.py) With this tool we can only make API calls towards an SMDP+. However, SGP.22 also defines a "reverse direction" ES2+ interface through wich the SMDP+ may make API calls towards the MNO. At the moment the only possible MNO originated API call is ES2+handleDownloadProgressInfo. Let's add a simple tool that runs a HTTP server to receive and log the ES2+handleDownloadProgressInfo requests. Related: SYS#7825 Change-Id: I95af30cebae31f7dc682617b1866f4a2dc9b760c |