-
-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: experimental Webxdc Integration API, Maps Integration #5461
Conversation
c767c43
to
ee7c1c4
Compare
50d01e9
to
87a6bac
Compare
0ed0e10
to
3198a85
Compare
not sure why CI is red suddenly |
CI is red because of #4476, unrelated to this PR here |
…quirements are passed for shipped .xdc
although maps for iOS (any maybe other systems) will stay experimental for 1.46, it is still good to get this in to move forward, get experience, bug reports etc. there are things missing pr, see above, but that is on purpose - it is already pretty much reviewed, adding now lots of things does not make much sense |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit overgeneralized, could have dropped "integration" completely and just name everything "webxdc maps" and merge webxdc::integration
and webxdc::maps_integration
for now. But otherwise looks good.
Co-authored-by: link2xt <[email protected]>
Co-authored-by: link2xt <[email protected]>
Co-authored-by: link2xt <[email protected]>
Co-authored-by: link2xt <[email protected]>
Co-authored-by: link2xt <[email protected]>
with this PR, when an `.xdc` with `request_integration = map` in the manifest is added to the "Saved Messages" chat, it is used _locally_ as an replacement for the shipped maps.xdc (other devices will see the `.xdc` but not use it) this allows easy development and adapting the map to use services that work better in some area. there are lots of known discussions and ideas about adding more barriers of safety. however, after internal discussions, we decided to move forward and also to allow internet, if requested by an integration (as discussed at #3516). the gist is to ease development and to make users who want to adapt, actionable _now_, without making things too hard and adding too high barriers or stressing our own resources/power too much. note, that things are still experimental and will be the next time - without the corresponding switch being enabled, nothing will work at all, so we can be quite relaxed here :) for android/ios, things will work directly. for desktop, allow_internet needs to be accepted unconditionally from core. for the future, we might add a question before using an integration and/or add signing. or sth. completely different - but for now, the thing is to get started. nb: "integration" field in the webxdc-info is experimental as well and should not be used in UIs at all currently, it may vanish again and is there mainly for simplicity of the code; therefore, no need to document that. successor of #5461 this is how it looks like currently - again, please note that all that is an experiment! <img width=320 src=https://github.com/deltachat/deltachat-core-rust/assets/9800740/f659c891-f46a-4e28-9d0a-b6783d69be8d> <img width=320 src=https://github.com/deltachat/deltachat-core-rust/assets/9800740/54549b3c-a894-4568-9e27-d5f1caea2d22> ... when going out of experimental, there are loots of ideas, eg. changing "Start" to "integrate"
…'s `manifest.toml` this partly reverts experimental #3516 that allowed any .xdc sent to "Saved Messages" to request internet. this helped on pushing map integration forward. meanwhile, however, we have that map integration (#5461 and #5678), that implies `info.internet_access` being set. experimental `manifest.request_internet_access` is no longer needed therefore. future will tell, if we revive the option at some point or go for more intrations ('sending' is discussed often :) - but currently it is not needed.
…'s `manifest.toml` this partly reverts experimental #3516 that allowed any .xdc sent to "Saved Messages" to request internet. this helped on pushing map integration forward. meanwhile, however, we have that map integration (#5461 and #5678), that implies `info.internet_access` being set. experimental `manifest.request_internet_access` is no longer needed therefore. future will tell, if we revive the option at some point or go for more intrations ('sending' is discussed often :) - but currently it is not needed.
…'s `manifest.toml` this partly reverts experimental #3516 that allowed any .xdc sent to "Saved Messages" to request internet. this helped on pushing map integration forward. meanwhile, however, we have that map integration (#5461 and #5678), that implies `info.internet_access` being set. experimental `manifest.request_internet_access` is no longer needed therefore. future will tell, if we revive the option at some point or go for more intrations ('sending' is discussed often :) - but currently it is not needed.
as discussed in several chats, this PR starts making it possible to use Webxdc as integrations to the main app. In other word: selected parts of the main app can be integrated as Webxdc, eg. Maps 1
this PR contains two parts:
to be clear: a Webxdc is not part of this PR. the PR is about marking a Webxdc being used as a Map - and core then feeds the Webxdc with location data. from the view of the Webxdc, the normal
sendUpdate()
/setUpdateListener()
is used.things are still marked as "experimental", idea is to get that in to allow @adbenitez and @nicodh to move forward on the integrations into android and desktop, as well as improving the maps.xdc itself.
good news is that we currently can change the protocol between Webxdc and core at any point :)
Webxdc Integration API
see
dc_init_webxdc_integration()
indeltachat.h
for overview and documentation.rust code is mostly in
webxdc/integration.rs
that is called by other places as needed. current user of the API is deltachat-ios, android/desktop will probably follow.the jsonrpc part is missing and can come in another PR when things are settled and desktop is really starting 2 (so we won't need to do all iterations twice :) makes also sense, when this is done by someone actually trying that out on desktop
while the API is prepared to allow other types of integrations (photo editor, compose tools ...) internally, we currently ignore the type. if that gets more crazy, we probably also need a dedicated table for the integrations and not just a single param.
Maps Integration
rust code is mostly in
webxdc/maps_integration.rs
that is called bywebxdc/integration.rs
as needed.EDIT: the idea of having a split here, is that
webxdc/maps_integration.rs
really can focus on the json part, on the communication with the .xdc, including teststhis PR is basic implementation, enabling to move forward on integrations on iOS, but also on desktop and android.
the current implementation allows already the following:
the current maps.xdc uses leaflet, and is in some regards better than the current android/desktop implementations (much faster, show age of positions, fade out positions, always show names of POIs, clearer UI). however, we are also not bound to leaflet, it can be anything
to move forward faster and to keep this PR small, the following will go to a subsequent PR:
Footnotes
maps are a good example as anyways barely native (see android app), did cause a lot of pain on many levels in the past (technically, bureaucratically), and have a comparable simple api ↩
only going for jsonrpc would only make sense if large parts of android/ios would use jsonrpc, we're not there ↩