sonnyhi there - what's the latest/greatest work on file sending with metadata? https://xmpp.org/extensions/xep-0385.html ?
sonny(interop is not of concern ATM)
jonas’sonny, the File Metadata ProtoXEPs currently in the pipeline
jonas’wait until tomorrow for them to get numbers
jonas’(though there is a chance > 0 that one of them is vetoed)
jonas’see https://xmpp.org/extensions/inbox/file-metadata.html for a preview
Ge0rGdamn, I need to do something about them.
jonas’Ge0rG, yes you do
jonas’please don’t let those expire, either
ZashA/B XEPs yeeeeeee
jonas’sonny, s/tomorrow/today/, we’re on tuesday alreay
sonnythanks - I don't understand the premise of that XEP - it removes a dependency to add a new one (and fragmention) while still relying on said removed dependency for thumbnails
sonnyI'll go with 0385 for now and see if I can contribute my thoughts to the list
jonas’it does not depend on jingle for thumbnails
jonas’and '385 does more than just file sending, it also does markup
sonny> A thumbnail element of the file, using the <thumbnail/> element defined in File Transfer Thumbnails (XEP-0264)
jonas’I do not see '264 depending on jingle.
sonnymy point is that it shows that depending on an external XEP isn't an issue - so I don't understand the premise of the XEP
jonas’oh, it was about which specific XEPs to depend on
sonnyif the issue is that Jingle is too big why not taking what's there and splitting
sonnywithout breaking changes / fragmentation
jonas’it’s not possible to do it without breaking changes as it’s in jingle’s namespace
jonas’the entire point is to remove it from jingle’s namespace
jonas’to avoid tying it in with jingfle
sonnyok I think the problem is that I don't understand how using a subset of the Jingle namespace may be problematic ?
jonas’when jingle gets updated, an entire mess starts
jonas’the jingle namespace changes
jonas’soo ... what now? do we leave the namespace of <file/> on the old "version", creating confusion? do we bump it, rendering the element invisible to everyone and causing massive breakage? do we bump it in jingle itself, but not for the use in '385?
sonnysplitting would prevent those issues from arising - XEPs have been split before
jonas’it is still in jingles namespace
jonas’which would then be the confusion part
jonas’or we move it into a different namespace -> exactly what file-metadata.html does
flowI am not sure how splitting would help here. the problem with the namespace would still exists. I guess the lesson here is that namespace should be minimally scoped
sonnyfile-metadata isn't a 1:1 with jingle so no
flowwhatever "namespaces should be minimally scoped" means in practice, there is probably a to fine-grained variant too
sonnyok so the problem is sharing namespace between xeps?
jonas’sonny, that is part of the problem
jonas’flow, most certainly there is
flowotoh I we hardly blame people that the <file/> element was designed under the jingle namespace: back then, it was probably not foreseable that other means of file transport would emerge
flowotoh I can hardly blame people that the <file/> element was designed under the jingle namespace: back then, it was probably not foreseable that other means of file transport would emerge
sonnyhow would you send File metadata element in a chat message? using reference type=data as well?