Consolidating Efforts

[TonyValenti]

Hi @zone117x I am the new maintainer of: https://www.nuget.org/packages/Mime-Detective/ https://github.com/MediatedCommunications/Mime-Detective

and have recently published an update expanding to over 14,000 mime signatures. Are you open to combining/joining efforts? If so, can you add TonyValenti as a admin on the MimeMapping nuget package?

[zone117x]

Hey @TonyValenti, I'm open to collaborating. Although, I'm not sure exactly what you're wanting to do, and I don't necessarily want to hand over admin privileges on a whim :)

Can you elaborate a bit on what you're trying to accomplish?

[dzmitry-lahoda]

would be nice if mime-detective depend on mimemapping, but guess that is impossible until mimemapping changed

[dzmitry-lahoda]

i would be glad to switch over to Mime-detective fully if there is a separate package just for mime types. assuming that mimemapping is subset of what is possible in mime-detective

[zone117x]

The OP requested admin permissions for this repo and did not follow up on what changes they were intending to make. Please let me know what course of action would be helpful.

[dzmitry-lahoda]

@zone117x it feels you do not have time to maintain repo. why not to give others to do stuff so efforts are not lost?

[zone117x]

@dzmitry-lahoda you recently opening an essentially useless issue https://github.com/zone117x/MimeMapping/issues/18 then closed it without providing any detail, and now you're doing the same thing in this issue.

I'm happy to continue maintaining this repo and respond to bugs or feature requests, but that requires people like yourself to spend at least 60 seconds writing an issue with a bit of thought out details to explain what you're trying to accomplish.

As it stands, it's not at all clear what you're trying to achieve from this issue or #18.

[Goksly]

Not sure I agree. I've looked at @TonyValenti's solution and it seems a bit like a sledgehammer (which people need from time to time) where as this solution seems more like a pair of tweezers. For my issue I just needed a simple "here is my file name, whats the mime?". I don't need something all singing all dancing 10000000 mimetypes and can get it from name, stream, a-another.

There are often many solutions for a reason.

Thanks for your efforts.

[zone117x]

Closing this issue as it doesn't seem productive.

[dzmitry-lahoda]

So we will not have a shared package for basic mappings for mime to an extension? Including problem details json https://github.com/zone117x/MimeMapping/issues/18 .

The base nuget is the list of ALL mime type strings.

And derived nigets are about mapping these to extensions (so it can be in base) or parsing out from specific stream.

[dzmitry-lahoda]

string rawExtension = "json";
string mimeType = MimeMapping.MimeUtility.GetMimeMapping(rawExtension);

Specifically this is no in shared nuget or named differently. GetConvetionalDefaultMappingFromExtension. Because it is not bijection by default and can depend on domain.

[zone117x]

@dzmitry-lahoda please open a new issue and clarify exactly what it is you are asking about. It seems like there may be a language barrier because I'm having a hard time understanding anything that you've brought up so far. I don't intend this to be rude, but each of your comments so far sound like auto generated bot spam.

[dzmitry-lahoda]

haha, I am is bot :) 🥑

I did not ready any specs and may be terribly wrong. But

1. Each MIME type is a globally unique string 1.1. In case it tries not to be so, the winning string with more authoritative RFC/specs and already implemented in Rust/Haskell wins 1.1.1 Rust and Haskell because they are strict and usually well-designed MIME libraries
2. Each mime type can be set to a unique map of numbers via enumeration. In C#
3. So 1 and 2 is good to be separate package for having a unified list and enum. 3.1. This package is easy to add new item because you should not add extensions or other stuff at same time. 3.2. It can be governed in shared repository by several people without single person authority.
4. Extensions. Map to extensions can be not bijective. So mapping to extension of mime type can produce 2 extensions. 4.1 So we can have new package on top of 3 which assume canonical map of mime type to extension. 4.2. There could be MIME to list of extensions too. 4.3. For extensions for not MIME type yet there would be error
5. Mapping of extension to MIME type should be other lib as for sure one extension may have have many mime types.
6. Having parsing library for extensions, file detection, stream detection is other package.

So collaboration can be in just having enum <-> MIME string map. In this case adding simple RFC string from #18 is easy as it does not require adding extensions, just MIME. Also it avoid blocking adding new MIME types because of risk the maintianer of git repo cannot handle adding new MIME for some reason.

[zone117x]

Okay, I can understand some of your requests from that.

Regarding splitting this lib into multiple packages -- I'm not really interested in that and don't see a whole lot of value in doing so. However, I'm not strictly opposed to it. If someone opens a PR that does this, I'd certainly consider it.

It sounds like you have a feature request to add a new method that returns a list of associated mime types for a given extension (and/or vice versa) -- this seems reasonable, although I don't think it would be a very common use case. If this is a feature you want, can you open a new issue for it?

Regarding the comments around "just adding a new entry" and "authoritative RFC/specs" -- this repo is already using the pretty authoritative dataset from jshttp/mime-db, which itself reads from IANA, Apache, nginx, and custom mime types that have been reviewed and permitted by the maintainers of the jshttp/mime-db repo.

You've mentioned RFC 7807 (i.e. application/problem+json) a few times. That RFC is a "proposed standard", and if it's not included in the datasets mentioned above, it doesn't sound like it has much traction anywhere. So I'm not sure if this repo (zone117x/MimeMapping) should start maintaining a custom list of mime types just for that.

cc @viceice if you have any thoughts

[viceice]

i don't need all those stuff.

i plan to make some more refactoring to make maintenance more easy. 🤗

[dzmitry-lahoda]

dotnet/aspnet is pretty heavy on RFC 7807 https://github.com/search?p=15&q=org%3Adotnet+problem+details+json&type=Code . And as it makes Result more typed and in process, Result like stuff will make more importance. so we have major framework (for C#) has that Mime .

[dzmitry-lahoda]

why https://github.com/jshttp/mime-db is authoritative?

imho could consider major web frameworks authoritative too - they have more starts and more real usage.

[dzmitry-lahoda]

my problem was simple - there is MIME in ASP.NET (main C# framework) and there is no such in MimeMapping.

[dzmitry-lahoda]

@zone117x

really reads for IANA? :)

[dzmitry-lahoda]

possible extension to that "root" package could be having mapping of MIME to a category, as it seems unique mapping of many to one without ambiguity.

[dzmitry-lahoda]

https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types wow,

 The table below contains both registered and (common) unregistered types.
# A type that has no unique extension can be ignored -- they are listed
# here to guide configurations toward known types and to make it easier to
# identify "new" types.  File extensions are also commonly used to indicate
# content languages and encodings, so choose them carefully.

and there are prominent items including problems json here

[dzmitry-lahoda]

so jshttp/mime-db is arbitrary repo by some opinionated JS developer who does not favor strict languages like Rust/Haskell/C# 11 (with result and records), ignores public authoritative lists and for sure ignores .NET ecosystem which we should tune for.

[zone117x]

@dzmitry-lahoda please see the purpose of this library by looking at the code here: https://github.com/zone117x/MimeMapping/blob/master/KnownMimeTypes.cs and here: https://github.com/zone117x/MimeMapping/blob/master/MimeUtility.cs

There are simply 2 functions that convert between a mime type and a file extension:

/// <param name="file">The file extensions (ex: "zip"), the file name, or file path</param>
/// <returns>The mime type string, returns "application/octet-stream" if no known type was found</returns>
public static string GetMimeMapping(string file) { ... }

/// <param name="mimeType">The mime type string, e.g. "application/json"</param>
/// <returns>One or more extensions matching the mime type or null if no match</returns>
public static string[] GetExtensions(string mimeType) { ... }

And a dictionary that has all of them:

/// <summary>
/// Dictionary of all available types (lazy loaded on first call)
/// </summary>
public static ReadOnlyDictionary</*mime-type*/ string, /*file-extension*/ string> TypeMap;

Mime types that do not have an associated file extension are not included in this library. Hence the name "MimeMapping".

---

https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types wow,

 The table below contains both registered and (common) unregistered types.
# A type that has no unique extension can be ignored -- they are listed
# here to guide configurations toward known types and to make it easier to
# identify "new" types.  File extensions are also commonly used to indicate
# content languages and encodings, so choose them carefully.

and there are prominent items including problems json here

As you can see in the apache resource that you quoted but seemingly did not read:

A type that has no unique extension can be ignored

And indeed, looking at that mime.types file, it is commented out and ignored:

# application/problem+xml

I'm not interested in bloating this library with thousands of additional constants for mime types that do not map to a file extension. Please use another library for that, or if none exist, then no one is stopping you from creating one.

[zone117x]

so jshttp/mime-db is arbitrary repo by some opinionated JS developer who does not favor strict languages...

I see no evidence of that. On the contrary, the repo looks quite unopinionated.

ignores public authoritative lists

No, it aggregates data from the exact same authoritative resources that you've mentioned yourself.

It appears that you are simply misunderstanding the purpose of both that repo and this repo. As I said in the previous comment, please look elsewhere for a library that contains a list of unassociated constants for every mime type.