ср, 19 июн. 2019 г. в 21:33, Ralph Meijer <[email protected]>: > 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
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
