Repository navigation
Make an additional "misc" section in the comparison with information about the libraries other than features #10
Description
This would be useful because features aren't the only thing to compare. These are some sections I propose:
- Documentation
- In-line (like ESDoc, YARD, JavaDoc etc.)
- Explicit (method documentation explicitly written out, like discord.js has)
- Tutorials
- maybe a value that rates the coverage of the documentation
- Examples
- Implementation details
- Are tokens cached?
- Is it async/threaded? If yes, how much and what parts?
- ...
- Extensions (I guess these are technically features, but unrelated to API support)
- Command parsing
- Temporary event handlers added on-the-fly, I call these "awaits", discord.js has "awaitResponse"
- (others)
- Security
- Does REST use HTTPS?
- Is wss used?
- Are cached tokens encrypted? If yes, how strong?
- Voice encryption?
- A field that displays the current amount of GitHub stars, using one of these fancy always-up-to-date image providers
Please propose other sections here you might find useful or necessary!
Activity
Auralytical commentedon Feb 1, 2016
FYI - HTTPS and WSS are mandatory (or will be very soon)
meew0 commentedon Feb 13, 2016
I saw this in my notifications and thought "finally somebody commented on this" but alas...
bwmarrin commentedon Feb 14, 2016
Well, I think it's a good idea. Just need to make a nice list. I bet if you've got an idea you could do a PR against the repo to add another section :) Ideally you would want to make sure whatever is listed is more fact-based and avoid subjective things.
meew0 commentedon Feb 14, 2016
To be fair, the current way is also a little subjective (Does "Yes" in a REST feature mean the user can do it at all using the library, or does it have to be nicely abstracted? Does sending messages include TTS? Does voice sending include transcoding? ...) I see what you mean though. Is there any particular thing in my list that's subjective in your opinion?
bwmarrin commentedon Feb 14, 2016
No, just a general thought. I think there's a few on my list that are subjective :). Like, "Does this lib suck" or is "lib code is hella messy"
abalabahaha commentedon Feb 14, 2016
Yes implies an abstraction. Nobody cares about TTS 😛
The list may get messy since lib devs will start clamoring to get/remove features to make their libs look better on the charts.
meew0 commentedon Feb 14, 2016
In that case, maybe we should get rid of the extensions part and focus on the other things. Maybe turn "Implementation details" into an "API compliancy" section that keeps track of token caching, on-demand chunking, rate limit respection and so on.
abalabahaha commentedon Feb 15, 2016
If the comparison is user oriented, there's not much point in putting API compliancy
If the devs are using this instead of keeping milestones/checklists/issues/reminders/Trellos/etc... pls
abalabahaha commentedon Apr 13, 2016
no
@uniquoooo stop abusing comment-editing
davidcole1340 commentedon Apr 13, 2016
oops
meew0 commentedon Apr 13, 2016
After thinking about it for two and a half months, I still think it's a good idea
suicvne commentedon Apr 14, 2016
i second that
AraHaan commentedon May 31, 2016
I think it is a good idea too @meew0.
abalabahaha commentedon May 31, 2016
GitHub recently introduced a feature called "reactions". Instead of making a comment to signal your reaction to a comment, you could simply click the reactions button and react to the comment.
bwmarrin commentedon May 31, 2016
+1
AraHaan commentedon Jun 1, 2016
@hlaaftana ez I am god. :P
abalabahaha commentedon Jun 9, 2016
haven't even agreed on what fields should be added lol
meew0 commentedon Jun 9, 2016
I'll do it
meew0 commentedon Jun 9, 2016
I'll make a PR and then we'll see
meew0 commentedon Jul 9, 2016
Actually, abal still needs to update the layout, so I'll reopen it and keep it open until that's done
abalabahaha commentedon Jul 9, 2016
no
EDIT: latency and ^
meew0 commentedon Jul 9, 2016
wow that was fast