On Wed, 08 Aug 2018 10:39:52 -0500 Sam Whited <s...@samwhited.com> wrote:
> On Mon, Aug 6, 2018, at 10:25, Tedd Sterr wrote: > > 3b) Proposed XMPP Extension: File Sharing Notifications - > > https://xmpp.org/extensions/inbox/fsn.html > > … > > Sam: [on-list] (agree with Kev, but not sure if it should go to > > Experimental) > > -1 > > As it stands right now there are a few things that really concern me > about this XEP. The only one really worth blocking for is the fact > that this allows users to send file upload percentages as part of the > chat state and I don't think this is something we want to encourage. > Instead, it would make more sense to me for each file sending > mechanism to have a way to send the total size of the file and allow > clients to calculate the percent complete themselves. This makes it > harder for a remote client to abuse the protocol (eg. to try and use > it as a "time until completion" meter that counts down instead, or to > be buggy and cause a meter to jump around on the remote client, > making the user think it's their client that's having issues, etc.) To solve this I think the best option would be to add a 'bytes-total' attribute to at least the initial sending notification, because the most commonly used protocols (HTTP File Upload/SIMS) only send a message after the upload has already finished. > Also, perhaps more importantly, this ties file percent completion to > support on the remote client, so a local client wouldn't be able to > support it consistently (some file transfers would have it, some > wouldn't). I agree with you on that, the progress shouldn't be OPTIONAL. > 3b) Proposed XMPP Extension: File Sharing Notifications - > https://xmpp.org/extensions/inbox/fsn.html > [...] > Georg doesn't like that there's no enumeration of all possible FSN > states, ... I can add an enumeration for the three states (creating, uploading, aborted). > nor an example of how to stop FSN, but likes the idea. Well, currently the client should just recognise the incoming file and should then end FSN. Of course this can lead to problems if the file sharing protocol is not supported by the remote client. I can add an upload-finished state. On the XMPP meetup in Berlin some ideas to improve the current file sharing with HTTP File Upload came up (thanks to Paul). If the progress is transmitted in bytes and the http upload server is also serving incomplete files, the remote client could already download parts of the file while the file upload still has not finished. And everytime the progress is updated the next part could be downloaded via. a range request. This way HTTP File Upload 'transfers' could quite be speeded up. Of course this is out of scope of FSN, but were an interesting thing for HTTP File Upload and SIMS in combination with FSN. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
