Supporting existing mime types. #65
Comments
|
Do you mean leveraging existing mime-types to describe the blocks (e.g. if you store a JPEG), so that the resolvers can correctly deal with the data? |
|
Exactly :)
…On Mon, Jun 25, 2018, 3:49 AM Volker Mische ***@***.***> wrote:
Do you mean leveraging existing mime-types to describe the blocks (e.g. if
you store a JPEG), so that the resolvers can correctly deal with the data?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#65 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAACQ59aZEoUwE-IU1eI41B_gxo5R_LSks5uAMBIgaJpZM4U0ph9>
.
|
|
I looked into it some time ago (I can't remember why, I guess there was some other issue triggering it). I was wondering if there was an easy way to get unique identifiers (as in "hex value") from the IANA Media Types. The only idea I has was scraping the Templates, getting a date from them and then assigning an increasing value ourselves. |
|
Why reinvent the wheel when there is an existing, extensible process for assigning them ? With higher level types, (image, video etc) ; splits off that, and when needed parameters to allow even more detail. Its not perfect for all situations, but its unlikely that any replacement would be perfect either, and it has the huge advantage that it integrates with other things - for example you can check what application your system wants to open the file in. If you invented your own system everyone would just have to carry around a big conversion table in their apps and figure out how to continuously update it to match a new hex type to the table. |
|
I think the goal here *is* to avoid re-inventing the wheel.
The problem is that we can’t use the raw strings for these mime types because it has to fit in a limited hex space. So the question is “how do we fit mime types into the space.”
Perhaps the first thing we should do is reserve a hex range for mime types, enough to fit all current types and what we can expect for future types.
If you invented your own system everyone would just have to carry around a big conversion table in their apps and figure out how to continuously update it to match a new hex type to the table.
People already do this for mapping file extensions to mime types. Yes, it’s annoying, but it’s actually a common practice. If you’re using `request` you’ve got one somewhere in your node_modules ;) The size of the map is actually much smaller than what it takes to actually implement using the types anyway.
I’ve seen CID’s be compared a lot to URL’s, but that’s only half the story. In HTTP the URL only tells you where the resources is, the Content-Type header tells you how to interpret it. But CID not only describes how to get the resource, it also describes how to interpret it. Two different CID’s can be created for the same block’s multihash so that they are interpreted differently.
… On Jun 25, 2018, at 9:55AM, Mitra Ardron ***@***.***> wrote:
Why reinvent the wheel when there is an existing, extensible process for assigning them ? With higher level types, (image, video etc) ; splits off that, and when needed parameters to allow even more detail. Its not perfect for all situations, but its unlikely that any replacement would be perfect either, and it has the huge advantage that it integrates with other things - for example you can check what application your system wants to open the file in.
If you invented your own system everyone would just have to carry around a big conversion table in their apps and figure out how to continuously update it to match a new hex type to the table.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#65 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAACQw_TYAwp0C1tX8O8Kn14g7fePlreks5uARYdgaJpZM4U0ph9>.
|
|
Note: The "codec" on the CID just tells you how to interpret the binary data as a structured IPLD object. It should not be used as an MIME type. |
|
@Stebalien Isn't there a huge overlap between MIME types and codecs? For me it makes sense to have a codec that tells me to interpret something like |
|
If you look at the existing list of multicodecs many of them already have registered mime types, so there's certainly overlap. If the only codecs were for dag nodes and all edge nodes were Here's a question that might shed some light on how to interpret this. If I'm building a fileserver on top of unixfs-v2 and the file name has an extension of To me, someone clearly encoded the node into I'll also note that projects like the IPLD graph viewer get much more interesting if we can signal mime-types for any edge node in a graph. It means that even the most abstract graphs people create that include images and other content can be interpreted and viewed much more easily. |
...
...
Yes. However, those aren't all IPLD formats. So, the issue here is twofold:
Really, we want a type system in addition to IPLD formats. However, IPLD formats are not a type system. The important difference is that, as long as a tool understands all the relevant IPLD formats, it can traverse/transform arbitrary IPLD DAGs even if it doesn't understand the types. Our current plan is to:
Aside: Yes, I know we have a GitRaw codec. IMO, we shouldn't. I don't know how that snuck in but that shouldn't be there. However, it is slightly useful because raw git objects are a bit special (they use the broken SHA1 hash and may be arbitrarily large). |
Do you mean there should be a codec for each Git Object type (commit, tag, tree)? If yes, why not changing it while we can? |
No, no, I'm just confused. I saw Now, really, there probably is a large overlap. Most files have some logical internal structure that could be decoded as a structured IPLD object. However, we have to be careful about adding new formats too eagerly as, again, we need to add support for those formats to every implementation. |
|
One cool aspect of mime in the browser world is content negotiation. I don’t see mime in the multiformats project, but I’m still finding my way around. At first glance IPLD seems like a reasonable place to empower user agents to pick content types, especially since different files with the same content might only be linked at the appplication layer otherwise. Sniffing is fine for serving files when only one format is available, but that path doesn’t lead toward robust content negotiation. |
|
At the CID/Block level we can't really negotiate the content because we can't change out the underlying data. If I have a Also, keep in mind that a CID is rarely an entire file. Files are written as a metadata node ( The current format doesn't support it, but it might be worth creating an issue in the You'd need something like: {
type: 'dir'
data: {
'filename;image/png': CID()
'filename;image/svg': CID()
}
}Or, alternatively, you could just use file extensions and a naming convention to do multiple formats of resources in a single directory and then write logic on top in order to pick which one is supported by the client. |
|
Media types (formerly MIME types) can contain more information than the suggested format allows. Some examples:
|
|
just adding a link for the verifiable credentials discussion. w3c/vc-data-model#421 |
I wanted to start a conversation about the best way to support existing mime types.
Specifically, I want to talk about data that doesn't have links but is often linked to, like images and video. It would be great not to re-invent the entire mime/content-type system for data without links.
Something along the lines of
mime[audio/aac].We also may want to consider the same for addressing compression of the format
mime[audio/aac][gzip].I looked around for a previous discussion around this but couldn't find anything. If there's another thread please point me at it :)
The text was updated successfully, but these errors were encountered: