Thanks for the feedback Jonas. Honestly I already thought about this after implementation and I agree with you. Removing "coding" in favor of always base64(u8) would make things way easier and still sufficient. And I'm fine with <amplitudes/>
--- Regarding references. Andrew Nenakhov gave me a good idea what to reference to when want to just an audio message. It's a text for clients which do not support SIMS. For example it can be an HTTP link to the audio record or something like "Go and install another client to listen this" in case there is only s5b stream available. So when SIMS-capable client renders this, it removes the referenced text. As far as I remember Andrew even added a special attribute the references where they have to be removed or not. So I believe his ideas could be applied here. Best Regards, Sergey сб, 7 сент. 2019 г. в 14:29, Jonas Schäfer <jo...@wielicki.name>: > On Mittwoch, 19. Juni 2019 19:46:02 CEST 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>. > > > > 2) Top-level reference doesn't state what has to be in "uri" which is > > required > > > > 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. > > > > 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> > > Nitpick: If you are going to implement this and intend on standardising > it, > may I suggest to use base64-encoded u8 bytes instead of the proposed > string > syntax? It will be smaller by approximately 63% for uniformly distributed > amplitudes and by approximately 33% for all-zeros (worst-case). (I am also > fairly certain that for the preview, u8 is fully sufficient.) (base64 > starts > to be consistently smaller (in the all-zeros worst-case) once you have > more > than 5 samples.) > > Another Nitpick: From your description, it is more like an <amplitudes/> > preview instead of a <spectrum/> (which implies something like a Fourier > transform or another way to obtain per-frequency values). > > kind regards, > Jonas_______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
