Skip to content
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

Clarify that payload and descr are optional #85

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

singpolyma
Copy link

No description provided.

@r10s
Copy link
Contributor

r10s commented Aug 6, 2024

for descr, i think, we should even remove it completely.

for payload.update i would keep it as is, also discussed with @adbenitez shortly. it is easy to pass payload: null - which is needed only for cornercases where devs are not really doing webxdc updates but only want add an info-message. often this is only a first step, to make things work and is considered as a bug even (eg. multi-device won't work in these games not using payload).

finally, changing the documentation for payload.update in the suggested way would break things for shipped app - while removing descr should be fine.

in general, we should be a bit careful here as and first change/check the apps, if needed. the page mainly acts as a spec for webxdc-app-devs, messenger-implementors is only a side topic.

@iequidoo
Copy link

iequidoo commented Aug 6, 2024

for descr, i think, we should even remove it completely.

I also think so, there's even no way to reliably set a description for a particular update, just the last description is used for a batch of updates, dropping the previously set description. Probably can be fixed by appending the existing descrition, but just dropping it is also fine

@singpolyma
Copy link
Author

What reason would there be to require putting a null payload? Other than deltachat current assumes this I understand, but surely this can be changed without too much disruption? It can be useful for a WebXDC to send a message to the chat without any accompanying state update. Obviously some messages will have a payload, but why require it for all of them?

@adbenitez
Copy link
Contributor

there is no technical reason that requires payload to be set, the only reason (as I think @r10s already explained) is so it is harder for developers to do a mistake and don't put a payload, it is not important that it is enforced 99% of all status updates will need it, only some rare cases would not need a payload, the main use case of status updates is to share status updates with the other devices, sending an status update without a payload is a corner case for some half-implemented apps or apps that only want to display a cosmetic message in the chat without really sending an status update, it is not worthy to change the rules for the exception use case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants