On 03/01/2013 02:41:39 PM, Matias A. Fonzo wrote:
> > There are people who like to have a full compressor/decompressor
> > in Busybox, performing better than gzip/bzip2.
>
> xz compressor then.
Precisely, adding the compressor, doesn't it imply adding more code?.
More code than the expected, I guess...
Adding more code is the price you pay for adding more functionality.
Busybox can't have _no_ code and do anything useful. So the question is
whether you get functionality worth the size and complexity penality of
the code you choose to include.
If you've got support for one end of an existing format, there's an
argument for supporting the other end because that code has to exist
somewhere for your code to be useful, and busybox tends to avoid
external dependencies where possible. This is similar to "if we're
going to have patch, it should handle applying hunks at offsets,
because otherwise people ahve to rip it out and replace it with a real
patch to do anything useful. And if we have patch, we should have diff
that can generate those..." Arguing that "our find should do -xdev" is
this class of argument: we already have code in this space and this is
part of the feature set that people actually use with that code, and
it's not too much code or complexity to be worth adding.
That argument isn't there for adding support for a _new_ format. When
you open a new can of worms you can make arguments based on use cases
or user bases, but Denys's argument was about where you draw the line
based on what busybox has already got.
Rob
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
