[Standards] SIMS issues

Sergey Ilinykh rion4ik at gmail.com
Wed Jun 19 19:05:20 UTC 2019


ср, 19 июн. 2019 г. в 21:33, Ralph Meijer <ralphm at ik.nu>:

> On 19/06/2019 19.46, Sergey Ilinykh wrote:
> > Hi
> >
> > I mostly implemented SIMS in Psi and see next problems
> >
> > 1) The requirement for top-level reference element looks strange.
> >     In Most of the case when I want to share something, I don't want to
> > refer to anything.
> >     If I really want to have a reference I would add it inside of
> > <media-sharing>.
>
> The idea here is very similar to Twitter Entities [1,2]. The primary
> advantage of using References is that you can provide a fallback to
> refer to a location where the media can be found, in case the client
> doesn't support certain media descriptors. I don't think the current
> examples show this very well, but instead of the "view" being referenced
> in the example, you could have a URL to access the picture in a browser.
>

> [1]
> <
> https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/entities-object
> >
> [2]
> <https://developer.twitter.com/en/docs/tweets/da
>
> <https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/extended-entities-object>
> Best Regards,
> Sergey
> ta-dictionary/overview/extended-entities-object
> <https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/extended-entities-object>
> >
>
> Also note that you don't have to use `start` and `end`, if you don't
> want to point to the plain text.
>
>
Then yes the xep has to be updated with use-cases. Since for now only
internal <reference> elements looks usable and it's hard to imagine any
good UX for the top-level one.


>
> > 2) Top-level reference doesn't state what has to be in "uri" which is
> > required
>
> I agree that References still needs a lot of work. However, beyond the
> value needing to be a valid URI, I think everything works. How I used
> it, was providing a URI to retrieve the resource over HTTP. Do you have
> any particular concerns here?
>
>
I rather see it like "most-available-uri". So an application should
prioritize
the sources and select one with highest availibility for top-level
reference.


>
> > 3) Seems like only one <media-sharing> element is allowed while it's
> > quite common to share multiple files at once with just one description.
> > Sending each shared file via separate stanza doesn't look to be a good
> > option since servers often limit sending rate and separate stanzas
> > somehow corrupt logical scope.
>
> But you *can* use multiple References. Would that work for you?
>
>
Can I? It has to be documented.


>
> > 4) I want to use SIMS for voice messages but there is no any metadata
> > for audio.
> >     I need at least duration and amplitude diagram there. Something like
> > following would be really
> >     nice to have:
> >     <audio>
> > <tune xmlns='http://jabber.org/protocol/tune'>tune data here</tune>
> >        <spectrum
> > coding="u8">0,3,135,237,210,195,243,137,...,4,4,1</spectrum>
> >     </audio>
>
> That sounds very interesting. I don't remember anyone suggesting a
> metadata format for this before and I didn't get to specify this in my
> previous project which would have eventually needed a format for voice
> messages. So what you could do is first define your own namespace and
> experiment with what works for your use case, and then eventually maybe
> submit it as a new XEP.
>
> Also, I support this element would go inside the <file/> wrapper?
>
>
Correct. I need it inside the <file/>. Probably I'll implement it like in
my example.

Thanks,
Sergey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190619/56c0495a/attachment.html>


More information about the Standards mailing list