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

Reply via email to