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.
