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
Invite-related events #708
Comments
Should the wormhole code itself appear in these events? |
I would lean towards "no" at first -- but also, the API reveals and accepts secret information so there's no particular reason not to in that sense. (However, the wormhole-code should be in the JSON returned from the creation endpoint, which I assume is sufficient for most UIs?) |
Do we want something more rigorous for the "state"? (the example looks like a free-form string, which probably has i18n problems at least .. I'm thinking something easy like "a list of permitted strings"). Walking through the code, we could at most include something for each
That's the happy-path. For "proper" progress we might want to include a notion of "step N of K" as well (i.e. so you can show a progress-bar or similar). Or this could be represented as "percent-done" I guess. |
(Getting |
Including the code would allow clients who did not initiate the invite to discover it immediately. I could see this being useful if, e.g., we want a GUI that displays and presents the state of all invites -- including those initiated by the
Yes, agreed. That was intended just an example. Having some list of pre-defined strings that clients could reference (like the ones you've outlined) would be much better. :) |
One semantic reason to keep it out of "mere status updates" is that it's a one-time use code, so even if a different UI initiated something it seems like no other interface should show the code to a human -- but also it's relatively easy to add later (especially if we're taking the "be tolerant of new stuff" approach to versioning instead of incrementing the version a lot). But as pointed out above, any other UI can still get at it... |
As a follow-up for #686 (comment) and after #694, consider also emitting "events" messages for the recently-added operations relating to magic-folder invites. Examples of such messages might be something like:
"Events" messages like these would prevent clients from having to manually query the
.../invites
endpoint in order to track state-related information and/or remove the need to await on (and, e.g., keep a reference to the Deferred for) the result of the.../invite-wait
endpoint. In addition, having an "invite-updated" event for each "phase" of the invite process would allow for finer-grained progress messages to be displayed to the user (since, currently,.../invite-wait
will only show the "final result" of an invite; there is no way to get intermediate/progress information without polling).The text was updated successfully, but these errors were encountered: