Rename //multipart/multipart.ts to //mime/multipart.ts

[ry]

As is done in Go https://golang.org/pkg/mime/multipart/

[axetroy]

How about media_types module?

should it rename to mime?

[ry]

I was thinking the same - but we should search Go's std lib to see if there's a corresponding structure.

[kitsonk]

Yeah, the only objection is that mime is very antiquated term. Can I blame Go for being stuck in the early 2000? media_type is much more correct name.

[zekth]

Yeah, the only objection is that mime is very antiquated term. Can I blame Go for being stuck in the early 2000? media_type is much more correct name.

Agree. See: https://tools.ietf.org/html/rfc6838

[ry]

Nevertheless, I think it will be easier if we stick to Go structure as much as possible.

So Let's move meda_type stuff into mime.

[kitsonk]

To be somewhat impertinent, I would never have known that Go uses mime except for this thread. Following Go only makes sense to people who have a Go background. I don't think that is the target for Deno, to make a secure JavaScript runtime for Go users. We have borrowed from Python, Rust, Go, Node.js, web standards, and ECMA script proposals as appropriate. I personally don't see what blind alignment to the Go standard library provides.

[ry]

@kitsonk Could you have a look at the documentation for https://golang.org/pkg/mime and let me know if it is trying to accomplish the same thing as our //media_type module here.

For example TypeByExtension() seems to correspond to media_type.lookup() ?

Although the naming might be anachronistic, pushing our code towards the Go directory structure and naming allows us to leverage high quality tests, documentation, and APIs. This is very helpful for organizing deno_std, because I (the reviewer) cannot be an expert in the myriad things we want to accomplish with this library (without dedicating a lot of time to it). However, if an API is in-line with Go's and has the same tests, I know it's more or less sane without thinking to hard (i.e. dedicating a lot of time to researching it). I think of the Go standard lib as an intellectual scaffolding for deno_std. See the statement I recently added to the readme.

[kitsonk]

@ry it certainly is similar, but the APIs in media_type are based on other open source JavaScript projects that are the foundations of Express, Koa, etc. so there is quite a bit of inconsistency in the API design which likely would make the tests not specifically re-usable in this case.

I get your point, I just wanted to vent my spleen a bit. 😁 I understand what you've added to the readme, don't know if I wholly agree with it, but I am not going to walk away in a huff. It just feels a bit constraining if anything.

[zekth]

I understand what you've added to the readme, don't know if I wholly agree with it, but I am not going to walk away in a huff

I agree with both of you. But atm staying more close to golang std give us the availability to port their tests cases and have a better coverage of the code. Illustration here: https://github.com/denoland/deno_std/pull/419

[ry]

@kitsonk Actually ya the fact that media_types is an oft used API is good enough to not change it.