Add request number to resolve "Support unambiguous request-response matching" - [merged] #92

Closed fraunhofer-iis-bot closed 1 year ago

In GitLab by @jannismain on Feb 25, 2020, 13:47

Merges 25-support-unambiguous-request-response-matching -> dev

Closes #25

In GitLab by @jannismain on Feb 25, 2020, 14:33

added 1 commit

f5aee6af - add support for japi_request_no

Compare with previous version

In GitLab by @jannismain on Feb 25, 2020, 14:34

unmarked as a Work In Progress

In GitLab by @jannismain on Feb 25, 2020, 14:35

added 15m of time spent at 2020-02-25

In GitLab by @jannismain on Feb 25, 2020, 15:28

added 1 commit

447b656e - add support for japi_request_no

Compare with previous version

In GitLab by @cstender on Feb 25, 2020, 15:51

Thank you for the MR. It should be mentioned in the documentation before the MR can be closed. Please also add a one-liner to the ChangeLog file.

In GitLab by @jannismain on Feb 25, 2020, 15:59

Is the doxydir/main.md the right place to document this? Or should I rather extend the doxygen header of the respective japi method?

In GitLab by @cstender on Feb 25, 2020, 16:03

Yes, main.md is probably the best place. Maybe we can create another subsection called features to add this kind of functions.

In GitLab by @cstender on Feb 25, 2020, 16:04

marked as a Work In Progress

In GitLab by @cstender on Feb 25, 2020, 16:04

changed target branch from master to dev

In GitLab by @jannismain on Feb 25, 2020, 16:24

added 1 commit

a5191ad8 - add documentation for japi_request_no key

Compare with previous version

In GitLab by @jannismain on Feb 25, 2020, 16:24

unmarked as a Work In Progress

In GitLab by @jannismain on Feb 25, 2020, 16:25

added 15m of time spent at 2020-02-25

In GitLab by @cstender on Feb 25, 2020, 17:06

I'm asking myself if we should force the developer to use strings for the request no. Maybe it's better to support any kind of json object. What do you think?

In GitLab by @jannismain on Feb 26, 2020, 09:20

I don't think array, object or bool make sense as japi_message_no values... But I see why number (integer, floats) might be nice, as the name implies one could use a number, whereas he has to use a string as of now...

Does json-c support some form of type-agnostic assignment or does libjapi have to do the type inference?

In GitLab by @cstender on Feb 26, 2020, 09:45

You can just get the value field of key "japi_message_no" with json_object_object_get_ex and simply add it to the response again. So you do not need to take care which type of object it is.

In GitLab by @jannismain on Feb 26, 2020, 09:54

added 1 commit

c4d98c06 - support any JSON value for `japi_request_no`

Compare with previous version

In GitLab by @jannismain on Feb 26, 2020, 09:55

I have added support for arbitrary JSON values :)

In GitLab by @jannismain on Feb 26, 2020, 09:55

added 10m of time spent at 2020-02-26

In GitLab by @cstender on Feb 26, 2020, 12:28

Commented on src/japi.c line 102

Ich denke hier erzeugst du einen Memory Leak, weil du den Ref-Count für den kompletten JSON-Request erhöhst. Es müsste reichen, hier jreq_no zu erhöhen.

In GitLab by @cstender on Feb 26, 2020, 12:32

Commented on doxydir/main.md line 148

Die Doku muss noch angepasst werden, sofern das andere Problem behoben ist.

In GitLab by @jannismain on Feb 26, 2020, 14:17

Commented on src/japi.c line 102

changed this line in version 6 of the diff

In GitLab by @jannismain on Feb 26, 2020, 14:17

Commented on doxydir/main.md line 148

changed this line in version 6 of the diff

In GitLab by @jannismain on Feb 26, 2020, 14:17

added 1 commit