On Wed, 2020-08-26 at 09:58 +0200, Thibault Molleman wrote: > That's a good idea actually! > Although I guess there is a part of me that thinks that having just a > simple image tag without any fancy stuff is still best for a primary > image (so that apps that want to implement it don't need to start > messing with this new format and can just load that simple url.
The beauty of HTTP Accept is that both the server and the client can fall back gracefully. If a client only supports receiving jpg images, the server would send the primary image, if it only supports HTML it would send a HTML page with the images embedded. If it supports our gallery format it would get them all. One URL, multiple responses. So if we had a POI with image= https://image-host-1.example/images?id=123456 and you opened that in a web browser (that wouldn't support a native gallery format) it would send something like "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q= 0.8". The server knows that the browser doesn't support the gallery format and prefers text/html application/xhtml+xml image/webp, then application/xml, then anything else (*/*), in that order. The server would respond with a HTML page that shows all the images. With something that supported the gallery format to would send, "Accept: application/gallery+json,image/*;q=0.9,text/html;q=0.8". Then if the server understands the gallery format it would reply with all the images and metadata. If the server didn't understand that mime type it would respond with a image, or HTML. This problem isn't just an OSM one, and this solution isn't really related to OSM. But it does mean OSM isn't locked to a single image provider like Wikimedia Commons. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging