Today I discovered an interesting inconsistency in Activity Streams specs while investigating [a Fedify issue].
-
@mariusor it's perfectly practical to serve what the requester asked for. it's not very practical to serve something they *didn't* ask for, instead of the thing they asked for.
any http server is capable of this. maybe they use query strings, maybe they don't. there are defaults in any case.
i mean, you probably encounter a cdn serving images like this multiple times every day, without even realizing it.
@trwnh I'm starting to feel you just like being contrarian.
I just said I serve what requesters ask for because my service employs content-negotiation. So if they ask for an image they get an image and if they ask for a document they get a document.
-
@trwnh I'm starting to feel you just like being contrarian.
I just said I serve what requesters ask for because my service employs content-negotiation. So if they ask for an image they get an image and if they ask for a document they get a document.
@mariusor no, i'm just trying to reach a mutual understanding.
content negotiation is fine if you are serving the same information for the same identifier. you have this idea of images being documents, people being documents, etc., and i have the idea that the representations are not the thing itself.
take for example the very popular and common pattern of doing something like this:
/image
/image.avif
/image?width=600
/image/thumbnail
/image@2xthese might all be "the same image" at the end.
-
@mariusor no, i'm just trying to reach a mutual understanding.
content negotiation is fine if you are serving the same information for the same identifier. you have this idea of images being documents, people being documents, etc., and i have the idea that the representations are not the thing itself.
take for example the very popular and common pattern of doing something like this:
/image
/image.avif
/image?width=600
/image/thumbnail
/image@2xthese might all be "the same image" at the end.
@mariusor again, this isn't theoretical, there are plenty of web servers doing exactly this.
you can find services of this sort all over the place:
Placehold
Placehold is a simple, fast and free image placeholder service to generate SVG, PNG, JPEG, GIF, WebP and AVIF placeholder images for your project.
(placehold.co)
and many widely-used softwares as well:
Images API
The Contentful Images API allows the retrieval and manipulation of image files referenced from assets.
(www.contentful.com)
GitHub - imgproxy/imgproxy: Fast and secure standalone server for resizing and converting remote images
Fast and secure standalone server for resizing and converting remote images - imgproxy/imgproxy
GitHub (github.com)
-
@mariusor again, this isn't theoretical, there are plenty of web servers doing exactly this.
you can find services of this sort all over the place:
Placehold
Placehold is a simple, fast and free image placeholder service to generate SVG, PNG, JPEG, GIF, WebP and AVIF placeholder images for your project.
(placehold.co)
and many widely-used softwares as well:
Images API
The Contentful Images API allows the retrieval and manipulation of image files referenced from assets.
(www.contentful.com)
GitHub - imgproxy/imgproxy: Fast and secure standalone server for resizing and converting remote images
Fast and secure standalone server for resizing and converting remote images - imgproxy/imgproxy
GitHub (github.com)
@mariusor the problem (for others) is that when you use the same URI to refer to different things, you can no longer distinguish between them. it's why the naive approach is to just use file extensions -- less ambiguity. you can trade content negotiation for explicit identification ahead-of-time. but it's quite tenuous to say that foo.jsonld and foo.png are "the same" in any meaningful sense. one is a description of an image, the other is a representation of the image. neither are the real thing
-
@mariusor the problem (for others) is that when you use the same URI to refer to different things, you can no longer distinguish between them. it's why the naive approach is to just use file extensions -- less ambiguity. you can trade content negotiation for explicit identification ahead-of-time. but it's quite tenuous to say that foo.jsonld and foo.png are "the same" in any meaningful sense. one is a description of an image, the other is a representation of the image. neither are the real thing
@trwnh who are these "others" that have issues with content negotiation?
The target for my software - this particular one I gave the icon example from - are browsers. And in a browser this content negotiation works perfectly fine, have a look see -> https://releases.bruta.link
Can you see the icon? You can. Can you open the icon in the browser in a new tab and still see it. Yes you can. Can you use curl on the icon URL, yes, and as it defaults to json, you get the JSON-LD representation. I think that's good enough for me. I accept that it's not for you and wish you good luck with the software that you're developing. I'll stop engaging now.
