[Standards] Proposed XMPP Extension: File metadata element

Jonas Schäfer jonas at wielicki.name
Thu Nov 19 18:41:00 UTC 2020

On Donnerstag, 19. November 2020 16:38:54 CET Marvin W wrote:
> Hi,
> On 19.11.20 15:29, Jonas Schäfer wrote:
> > - I do not like the dimensions element carrying two values. I suggest to
> > use separate width/height elements. Same motivation as for 1st normal
> > form for databases.
> Agree. Not sure where I copied that from, but splitting in width/height
> definitely makes sense.
> Also, might even be worth considering adding something for 3d scene
> files, but that's probably future talk for the next few years ;)


> > - Did you consider using the `flick` unit for the duration, instead of
> > milliseconds? See for example https://github.com/facebookarchive/Flicks
> I was originally using seconds, but then decided that seconds are too
> low accuracy for properly displaying a slider or progress bar when the
> audio/video is just a few seconds. I can't imagine any usecase where
> flick accuracy would be needed, but if there are, I'd rather like to
> move those in a separate field. The <length/> is mostly for something
> that can actually be displayed to normal users, and flick unit accurate
> numbers certainly can't, except when rounded to millisecond accuracy or
> less ;)

Right, that’s all I wanted -- consideration. I didn’t expect this to be 
useful. Milliseconds *feels* arbitrary, but rationally I think it is a good 

(Things going on in my head: "seconds would be prefix-less, but for 
appropriate precision, decimal digits would be required -> float support"; 
"but how about using fixed-point?"; "yeah, then we can go with milliseconds 
right away instead of bothering to write *that* down properly"; "but 
milliseconds :(")

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20201119/bf9436af/attachment.sig>

More information about the Standards mailing list