|| at Apr 24, 2013 at 3:11 pm
After examining the code I'd have to agree with Minux that image/bmp is not
ready for prime time. The code has comments about limitations - including
the lack of RLE support. The API for both bmp and tiff is minimal and at
first glance already conforms to the public interface of png/gif/jpg so I
don't think API problems are really an issue.
As I see it bmp for sure and probably tiff don't belong in main tree (yet).
A reasonable goal should be to improve them so they eventually are ready
but with constrained resources it may be a (long) while. I guess what is
missing is a statement (hopefully from someone with authority to make the
decision) of what needs to be fixed before they ARE ready. Does every
feature need to be present and tested or is an 80% solution acceptable? IF
you say 100% then I urge you to take a look at the 45% solution present in
archive/zip. Personally I don't have a burning need for a tiff or bmp
decoder. But if someone did have such a need and was willing to work on it
and contribute to the library the current state of affairs doesn't do much
to encourage them.
On Wednesday, April 24, 2013 10:29:28 AM UTC-4, Volker Dobler wrote:
Am Mittwoch, 24. April 2013 16:21:24 UTC+2 schrieb Hotei:
If go.image isn't ready yet then that's a pretty good reason for keeping
separate for now. Can you give us a link to where the open issues for
sub.repo are tracked? I tried code.google.com/p/go/issues but they don't
seem to have anything listed as open for images/tiff or images/bmp.
It is not about "not beeing ready", it is about "there is no guarantee
that this API
won't change until Go 2.0".
On Wednesday, April 24, 2013 9:49:35 AM UTC-4, minux wrote:
On Wed, Apr 24, 2013 at 9:39 PM, Herbert Fischer wrote:
Are there some concerns with API size in the stdlib?
I'm not sure about this, but IMHO, API size of stdlib is not a big
issue, as long as there
is people willing to maintain the included packages.
If not, I agree and think the best way would be to merge go.image into
the stdlib since the main repository is actively maintained and the
contribution process is well organized.
why do you think the sub-repository contribution process is not well
the contribution process to sub-repositories is the same as that of the
Merging back to the main repository means the API must be frozen and no
API changes will be accepted.
Considering the current status of the two image packages (tiff and bmp),
I don't think they
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.