api: cffi: add dc_event_get_json which gives the jsonrpc representation of an event
#6326
Conversation
…tion of an event This has the advantage that fields are named/labled and there can be potentially more than 2 (data1 & data2) fields on the events. This removes the need for the (potentialy confusing) overloading data1 with `dc_event_get_data1_str` to add more information to events. And also allows gradual/partial moving to the jsonrpc api, when needed or wanted.
|
needs to be conditional on the jsonrpc feature flag. But I also ask myself if we still need the jsonrpc feature flag at all? edit: I made #6417 |
|
are there no tests against the jsonrpc API in the core? |
|
We kind of want to deprecate legacy Python bindings at some point, and it is the only part that tests CFFI. What we really need is some UI to use this API instead of the old API. I'm also fine with merging this as is if it makes experimenting with this easier, if it's broken it is not a problem, but we need iOS or Android or DeltaTouch to use it eventually. |
for Android/iOS, there is no need nor plans just now. but on the next event added, it may become handy - so, not sure if it makes sense to merge this PR, usually, we do not do that without UI counterpart. i would be fine to put it to resurrection and revive it, it if gets needed |
This has the advantage that fields are named/labled and there can be potentially more than 2 (data1 & data2) fields on the events.
This removes the need for the (potentialy confusing) overloading data1 with
dc_event_get_data1_strto add more information to events.And also allows gradual/partial moving to the jsonrpc api, when needed or wanted.
Context/intention: seems logical and was easy to add, no personal grand plan behind it, just wanted to make life easier for UI devs.
Disclaimer: haven't tested it yet, but should work as it is really simple.