Closed Antosser closed 11 months ago
Usually computers doesnt render size using Base-2, the use of kilo
, giga
, and mega
is
more of jargon than actually the value.
Please take a peek on these two pictures:
This is the current main
:
This is this branch proposal:
My observations are:
Usually computers doesnt render size using Base-2, the use of kilo, giga, and mega is more of jargon than actually the value.
Windows uses binary but incorrectly displays KiB as KB
The point is, the way it is right now is incorrect. The number is binary while the unit is decimal
but in neither of both the size matches OS specific size
That's because the number in http-server is in KiB, while the OS size is in bytes. It has almost nothing to do with floats
Usually computers doesnt render size using Base-2, the use of kilo, giga, and mega is
more of jargon than actually the value.
Windows uses binary but incorrectly displays KiB as KB
Im struggling finding an OS that uses Base-2 notations in their data size notations.
Even though I consider you are technically right, I still have to consider the user base counter part, which not only involves the technical side of the problem, but the educational.
OS developers and the Software Industry have been using Base-10 notation for years.
This would introduce confusion, and also would affect current users perception on the data size values because HTTP Server would render a different unit than their systems.
The point is, the way it is right now is incorrect. The number is binary while the unit is decimal
Thing is, no popular system uses binary notation. Its a matter of usage and how the data industry popularized data units.
Using Base-2 would be against that, please take into consideration all kind of users.
but in neither of both the size matches OS specific size
That's because the number in http-server is in KiB, while the OS size is in bytes. It has almost nothing to do with floats
Please pay attention to the size
value in macOS Get Info window and compare it to HTTP Server's size value.
This commit now uses the humansize crate, which allows choosing BINARY vs. DECIMAL. This is what if now looks like:
These are the possible options provided by the crate:
This PR removes
src/utils/fmt.rs
, since it only had theformat_bytes
function, which can also be used from another library.The implementation of
format_bytes
is also incorrect.1024 bytes
is not equal to1KB
, as the test indicates.1024 bytes
is equal to1KiB
, and meansKibibyte
, wherebi
stands for binary. Why not just use a library for that? That would eliminate such bugs.The PR changes the file size type from
String
tou64
and adds a_bytes
postfix to the property name.I would love to store the file size as the
Size
struct provided by thesize
crate and remove the postfix, butSize
doesn't implement theSerialize
trait, and we'd have to wait for that before we can do that.