-
-
Notifications
You must be signed in to change notification settings - Fork 19
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
Implement MSC4039 download_file action #99
Conversation
Signed-off-by: Michael Weimann <michael.weimann@nordeck.net>
Signed-off-by: Michael Weimann <michael.weimann@nordeck.net>
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.
other than that, works for me
test setup:
|
|
||
export interface IDownloadFileActionFromWidgetRequestData | ||
extends IWidgetApiRequestData { | ||
content_uri: string; // eslint-disable-line camelcase |
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.
Why does this need to be an exception? Is it taken directly from the wire and we don't want to convert?
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.
same as e.g.
original_request_id: string; // eslint-disable-line camelcase |
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.
OK, careful of cargoculting then - the other instance has zero comments on why the exception exists too. Doesn't feel like a blocker though.
|
||
export interface IDownloadFileActionFromWidgetResponseData | ||
extends IWidgetApiResponseData { | ||
file: XMLHttpRequestBodyInit; |
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.
I guess this is more a comment on the MSC, but maybe body
would be a better name for this? file
implies https://developer.mozilla.org/en-US/docs/Web/API/File which is not one of the many things this type can be. Probably doesn't need to match the upload type (although that isn't a file object either...)
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.
Also, another comment that's really on the MSC, but... why XMLHttpRequestBodyInit
? This seems like a bit of a weird union type defined in the fetch API for... actually I'm not even sure why, it doesn't seem like it's referenced. The react-sdk impl just sends a blob. If something sends ones of the other types, how would it go about determining what it's actually got? instanceof
in js can be... special.
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.
The explanations I can offer is, quoting from the MSC:
To your first question:
response.file
mirrorsdata.file
of theupload_file
action and is aXMLHttpRequestBodyInit
that is supported as a data type in thepostMessage
API.
To be consistent, would you think that we would also have to rename the upload's data.file? We would then need to spend some thoughts on backwards compatibility.
To the second one:
XMLHttpRequestBodyInit
is reused again here because it was already used in
file: XMLHttpRequestBodyInit; |
Again, to be consistent we would need to change it there too and manage version incompatibilities.
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.
Well, IMO renaming file on the upload API would be clearer, but that's for the MSC discussion anyway. If we think the right way to go is to change upload too, then we'd need a new version of the MSC anyway, so we may as well implement download as the MSC is now and then change both at the same time, at a later date?
|
||
return this.transport.reply<IDownloadFileActionFromWidgetResponseData>( | ||
request, | ||
{ file: result.file }, |
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.
Again, more for the MSC but... what about large files? I guess the answer is that since there's no specific limit on postMessage, we can add a different API later if it's needed?
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.
I don't see an obvious issue with postMessage at a glance. Mostly, we assume that we can do whatever we already can do for uploading. This update to MSC4039 seeks to address Authenticated Media, which got overlooked so far for the widget API. The real answer is probably to revamp the widget API entirely to enable widgets to use their own scoped access tokens to access the C-S API directly, but we won't get there before Matrix 1.12.
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.
Well, I don't think trying to download a 1GB file over the postmessage API is going to be a great user experience, but yeah, if this is more of a stop-gap solution until we have scoped access tokens then that's probably okay.
Signed-off-by: Kim Brose <kim.brose@nordeck.net>
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.
In summary I think this seems broadly okay, I'll transfer my MSC-specific comments over the MSC. I'm happy to merge this if you are?
Quality Gate passedIssues Measures |
Thank you, I think we're ready to merge. Full context: weeman is on holiday and the rest of the team from Nordeck is taking over, which is why I'm responding to your comments and pushing changes, but cannot resolve conversations etc. |
Adds support for the
download_file
action according toMSC4039
.It contains neither the timeout nor the encryption part. This can be done in subsequent PRs.