[Standards] File sharing states for XEP-0085: Chat State Notifications
jonas at wielicki.name
Tue Jul 17 13:36:06 UTC 2018
On Dienstag, 17. Juli 2018 15:09:16 CEST Linus Jahn wrote:
> Hello Matthew and Ненахов,
> thank you for your answers.
> On Mon, 16 Jul 2018 13:59:23, Matthew Wild <mwild1 at gmail.com> wrote:
> > Authoring a new XEP for this case would not be hard. Take a look at
> > https://xmpp.org/about/standards-process.html for details about
> > getting started.
> Thanks, I'll do that.
> On Mon, 16 Jul 2018 14:12:11, Ненахов Андрей
<andrew.nenakhov at redsolution.ru> wrote:
> > Actually, we've recently a 'type' attribute in development Xabber
> > for Web build so we can display messages like 'recording an audio
> > message', 'recording video message', 'uploading file'. Works ok,
> > third-party clients just see it as simple 'typing'.
> I think in the XSF MUC they agreed on that it's a bad idea to add
> attributes to another namespace, so I'll use a subelement.
> While thinking a bit about the new XEP, I came to the conclusion that
> the uploading information could also be added to other states than
> <composing/>. For example in <paused/> to indicate that the user has
> aborted the upload. It should even be possible for <inactive/>, because
> the client can continue to upload while the user is doing something
Yes. Not tying this to <composing/> seems like a good idea for flexibility. My
suggestion would be to put your new elements next to the existing XEP-0085
elements, not as children of them. E.g.:
@progress would be optional and give the upload progress from 0 to 1. @type
would indicate what’s being uploaded (although I’m not 100% sure if that makes
sense to have). The valid values for @type should be enumerated; it might make
sense to allow use of MIME types here.
> Apart from that, there should be states for uploading media files and
> states for the creation of the media files (user is recording
> audio/video or taking a picture).
I’m not sure what the use-case for this would be in general.
> The third point I thought about was if the uploading progress should
> also be transmitted. I think this can be useful in situations where
> the upload takes very long, so the chat partner can at least estimate
> if the file will be there in a few seconds or it will still take an
> hour. The progress should probably not updated more often than once a
See above :-).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards