Hi all, My two cents for the thumbnails issue and the comment: "The main advantage is a client code simplification. You need tons of work to generate thumbnails for images and video files. Also, we cannot just say a developer: hey, if your UI is slow, fix it. In the most cases developers will find just an easier way and will not deal with jabber, because simplier solutions exist. We now see this every time. We're lacking developers because of this.' I am working on an application that is very dependent in file transfer related extensions, and HTTP upload would be extremely useful.
Existing protocols are complicated or slow or don't compatible among different clients/libraries/setups etc. My 2 cents is the extension should be the simplest possible. Thumbnails would be cool, but reliable XMPP file transfer is missing, and I would prefer to have the maximum compatibility among libraries and servers implementing the extensions, than having to generate thumbnails myself. In general I think that XMPP might be missing developers not because features are missing but because of non compatible extensions lists and extension implementations among different libraries, servers and applications. All the best! On Fri, Sep 18, 2015 at 12:11 AM, Evgeny Khramtsov <xramt...@gmail.com> wrote: > Thu, 17 Sep 2015 21:49:04 +0200 > Daniel Gultsch <dan...@gultsch.de> wrote: > > > Hi, > > > > a couple of reason that speak against using the HTTP upload to create > > thumbnails. (In no particular order) > > > > - the service should be agnostic towards the files. I assume you are > > proposing to create thumbnails for images? What about video files? > > what about images in exotic formats? do I know before hand if the > > server will create a thumbnail for me? Will this be random? do you > > add a way to discover 'known image formats'? > > This is not a very big problem. If a server is unable (unwilling) to > generate thumbnails it sends empty response. A client then will > generate a thumbnail if needed. > > > - in an idealistic world we will have more and more end-to-end > > encryption. so any thumbnail creation will not work for those images. > > so clients that handle end-to-end encryption will have to provide a > > way to create their own thumbnails anyway. > > If someone wishes not to using thumbnails, it may ignore it in > the response. I'd also like to admit, that crazy encryption of > everything which is very popular nowdays should not affect everyone. I > personally don't care whether my messages will be intercepted or not. > So I don't want to suffer from limitations of any sort of encryption. > If you want - go ahead. I don't. But that's a completely different > topic. > > > - potential security leaks. For a server it is much safer just to copy > > files and store them than to actually process them. media formats > > have a long history of being exploitable. > > There are a lot of image servers which produces thumbnails without > being exploitable. Care should be taken of course. > > > - very little actual gain. creating a thumbnail is not that expensive. > > especially since your device is probably awake at this point anyway. > > If the thumbnail creation will freeze your UI is probably up to your > > implementation and can probably be avoided in most cases. the only > > small benefit would be that you don't have to upload the actual > > thumbnail. but considering that thumbnails are small... It don't > > really see it. > > The main advantage is a client code simplification. You need tons of > work to generate thumbnails for images and video files. Also, we cannot > just say a developer: hey, if your UI is slow, fix it. In the most > cases developers will find just an easier way and will not deal with > jabber, because simplier solutions exist. We now see this every time. > We're lacking developers because of this. > > > besides as of right now we don't have a proper way to send thumbnails > > anyway. If we come up with a way to send thumbnails as dedicated > > thumbnails it might be worth considering to send them base64 encoded > > inband anyway. (right in the message stanza (you have to keep them > > smaller than lets say 5KiB but for thumbnails thats probably > > manageable) > > We have XEP-0264. > > I'd also like to note that if you don't want server-side thumbnails, > don't use them. But there should be an option for those who wants. >
