Closed wyatt-herkamp closed 5 years ago
When will we be seeing 3.0?
@NunoAlexandre suggestion was added. getValue() -> to getContentType() value -> contentType
@wherkamp if you can add SVG and we'll merge this. I'll have to rework most of what I have in my stash anyways so there's no point in keeping this stuff frozen.
@LordFokas https://github.com/NanoHttpd/nanohttpd/pull/499/files#diff-6dbbc038ff7d75dc3b7c644ef0831160R59 Already added
I have three remarks still:
instead of
There is no reason to have both getContentType()
and toString()
This branch adds this module but doesn't use it anywhere. What would be the added value then? Shouldn't it be plugged in?
@wherkamp you have to leave the default toString()
, it's not the same thing as the content type.
@NunoAlexandre something may be missing but the MimeType is indeed used.
@LordFokas
something may be missing but the MimeType is indeed used.
Where exactly is it used? This commit only adds the MimeType module but it doesn't seem to be used anywhere.
@NunoAlexandre it is meant to be plugged in here: https://github.com/NanoHttpd/nanohttpd/blob/master/core/src/main/java/org/nanohttpd/protocols/http/response/Response.java#L132
And yes, as I suspected, things are missing, and some other semi-related things are horribly wrong because of course they are. Fixing this library is a job for masochists.
So what needs to get changed for this PR to be accepted?
Nothing, I just skipped a beat to give Nuno a chance to give some more input.
However, now that you mention it, I have one final request. Can you, on the response class, create another response method that uses your MimeType instead of a string? The implementation for now should simply redirect to the string version with the contentType from the mime object (it's a 1-liner :p )
Thanks! :) I promise (unless there's a mistake somewhere) I'll merge right after that ;)
@NunoAlexandre (my 2 cents) you could squash and merge if you're not so happy with these commit messages showing up in history. Plus, 5 commits with such small changes don't make sense.
@LordFokas @crearo I am not a member of this project, my feedback is merely suggestive.
Now, those commits are bad, but it's up to the members of the project to reconsider the standard.
@crearo, these should just be squashed indeed!
@NunoAlexandre being "just some guy" with "merely suggestive" but good feedback is how I became a member in the first place 😉
And just because you're not a member that doesn't mean I don't want to hear what you have to say, of course, and I'll be even more willing once I see you commit good stuff and giving more good feedback. I don't exactly disagree with what you've said above (about the toString()
) but I do want to keep things simple for the devs but also the users, and semantic / suggestive names are crucial (trust me, I've been mucking with this code for years!).
Not everything the community sends PRs for is good (damn I've fought some battles to keep some nasty crap from being pulled in the past) but I also have the responsibility to drive the community to do things and PR them, so as long as what's coming in is better than what we currently have it's already a great start. This PR for instance matches what I want for 3.0 so I'm glad to have it, even though not everything is perfect (and of course I won't forget to squash).
Small progress is better than no progress 😄
@LordFokas is this ok?
I think I fixed it. Some how?? I tried to remove the 50 commits. But I messed up in my second commit message. I hope that doesn't interfere with the PR, I am sorry. If it does I can try to fix it.
but I do want to keep things simple for the devs but also the users, and semantic/suggestive names are crucial
Right, but you better reconsider what you consider simple and good naming.
We are talking about the MimeType
type here. If I read mimeType.toString()
, it's simple and clear, while mimeType.getContentType()
isn't. What's the content type of a mime type? It's mixing things up: https://stackoverflow.com/questions/48691415/content-type-vs-mime-type.
@wherkamp I don't think so.
MimeTypes
should be MimeType
(singular)private String contentType
attribute better be mimetype
or value
as it was before.getContentType()
and bring the toString
back (see discussion above)Added evgk/patch-1
tells us nothing of what the commit does. Could you rename it to something like Integrate MimeType
You can git rebase -i origin/master
to amend your commits title and changes in this branch.
I am done. Here use it if you want I don't care. This is too much work for one stupid file. https://gist.github.com/wherkamp/96f436833789cf4c1e6dd252017aa110
@NunoAlexandre this is what I meant by driving the community to do things. Just because you know how to code and use git doesn't mean you know how to handle what goes on on GitHub. And just because you wanted to nitpick every little detail that's one less user willing to get stuff done. Great job.
Ok in @NunoAlexandre 's defence, there was nothing wrong in what he said. I hate lousy commit messages, and enums typed in plural.
Plus, having raised a couple issues before I know @LordFokas you prefer quality code. Better to prefer that than a larger community trotting bad code + history everywhere. That said, @NunoAlexandre : probably a good time to open a PR for this :D I've had to create a separate MimeType
class because it wasn't already there when i was using nanohttpd.
If you've been here long enough then you know I can be ridiculously pedantic about things, but I'll have you know there's times I don't think it's appropriate. I'm not going to explain everything behind my logic with my acceptance here... also there's the fact I was ready to squash all that into a commit with a meaningful message.
Plus, you can easily educate users that PR bad code, and put aside users that refuse to be educated.
This being said, I think we should maybe draft a CONTIBUTING.md
file to smooth out future PRs that might tend to go like this...
A. That class was a copy of some I used in my own projects. So I thought it might be nice inside of NanoHttpd. B. 3.0 is it going to be a rewrite?
3.0 is meant to be a refactoring. A massive one. So massive in fact that I have all the code I want in a VM somewhere and all the tests got fucked up and I ended up never commiting it.
But boy, does it have a good structure. I might have to redo all of it, step by step to get it to decent working condition.
Basic MimeTypes. Source for MimeTypes: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types