Haha. Is that a stab? Getting into the mood for the web framework smackdown?
Eelco
Martijn Dashorst wrote:
+1, I'm all for keeping to official standards, but pragmatic enough to
avoid them when they break stuff. One of the reasons I'm on Wicket ;-)
Martijn
Christopher Turner wrote:
I don't think we need to convince the IEEE - although I'm happy to
raise a mob of geeks and mathematicians and pay them a visit ;)
Until ALL operating systems and computer architectures base their
file sizing around 1000 bytes instead of 1024 bytes then we have to
stick to 1024 bytes as this the only way we can size buffers and
files correctly. Who really cares whether 1024 is called a Kilo or a
Kibi, my computer says a file is 100K and allows it to be up to 10240
bytes in size - that's all we need to know!
+1 for closing the bug.
Regards,
Chris
> Ok, I'm convinced. Who's going to convince IEEE?
>
> Let's close the bug and make it clear that we don't have to
> start this
> discussion again next month.
>
> Eelco
>
> Christopher Turner wrote:
>
> > As far as I have been able to test (Windows, Solaris) all operating
> > systems seem to use 1K == 1024 bytes when dealing with disk sizes,
> > files sizes and so on. Therefore, if we are using this
> information in
> > relation to buffers or file size checking then we MUST keep
> 1K == 1024
> > bytes. Reasons being:
> >
> > - We don't want buffer overruns by a small number of bytes. This is
> > inefficient.
> > - If we are using the conversions to check size of uploaded
> files then
> > a file that is 10K on a user's system can be between 9217 and 10240
> > bytes. If our max upload size was 100K and we were using the 1K ==
> > 1000 bytes conversion then any files between 10001 and
> 10240 bytes we
> > seem the correct size to the user (as reported by their OS)
> but would
> > fail on the size validation - not good.
> >
> > I'm therefore very strongly -1 against this change. 1K should always
> > equal 1024 bytes (unless processor architecture changes to
> use base-10
> > logic). If people want alternative conversions for their particular
> > application then they should not be using the Wicket
> utility classes IMHO.
> >
> > Regards,
> > Chris
> >
> > >
> > >
> > > the only thing is we are using them for making max
> buffers So if we
> > > use it to make a buffer that should hold a 134KB file
> > > then:
> > >
> > > XXXsetBuffer(Bytes.kilobytes(134));
> > >
> > > should be able to hold that file exactly...
> > >
> > > Now the question is.. Is a file which is 134KB (windows reports
> > > that) 134000 bytes or not?
> > >
> > >
> > > johan
> > >
> > > Juergen Donnerstag wrote:
> > >
> > > >This was a request from Gili.
> > > >
> > > >"We should use 1 kilobyte = 1000 bytes as mention here:
> > > >http://encyclopedia.laborlawtalk.com/kilobyte
> > > >
> > > >This standard has been around since at least 1998 and I
> personally
> > > >believe most people think in terms of this standard anyway (i.e.
> > > >decimal, not binary system)."
> > > >
> > > >Based on the answers I have seen so far, we agree on
> this change.
> > > >It that correct? What are your votes?
> > > >
> > > >Juergen
> > > >
> > > >
> > > >-------------------------------------------------------
> > > >SF.Net email is sponsored by: Discover Easy Linux Migration
> > > Strategies
> > > >from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> > > >informative Webcasts and more! Get everything you need
> to get up to
> > > >speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id
<http://ads.osdn.com/?ad_idt77&alloc_id>
> > <http://ads.osdn.com/?ad_idt77&alloc_id
<http://ads.osdn.com/?ad_idt77&alloc_id>>492&op=click
> > > >_______________________________________________
> > > >Wicket-develop mailing list [email protected]
> > > >https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > > >
> > > >
> > > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Discover Easy Linux Migration
> > > Strategies from IBM. Find simple to follow Roadmaps,
> straightforward
> > > articles, informative Webcasts and more! Get everything
> you need to
> > > get up to speed, fast.
> > > http://ads.osdn.com/?ad_id=7477&alloc_id=16492
<http://ads.osdn.com/?ad_id=7477&alloc_id=16492>
> > <http://ads.osdn.com/?ad_id=7477&alloc_id=16492
<http://ads.osdn.com/?ad_id=7477&alloc_id=16492>>> &op=click
> > >
> > > _______________________________________________
> > >
> > > Wicket-develop mailing list [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > >
> > >
> >
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies from IBM. Find simple to follow Roadmaps,
> straightforward articles, informative Webcasts and more! Get
> everything you need to get up to speed, fast.
> http://ads.osdn.com/?ad_id=7477&alloc_id=16492
<http://ads.osdn.com/?ad_id=7477&alloc_id=16492>> &op=click
>
> _______________________________________________
>
> Wicket-develop mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
