FAQ
What is the reason for these image formats be in separate repositories?

--
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jesse McNelis at Apr 23, 2013 at 11:33 pm

    On 24/04/2013 9:15 AM, "Herbert Fischer" wrote:
    What is the reason for these image formats be in separate repositories?
    Jpeg, PNG, and GIF are very commonly used. Tiff and BMP much less so. 'Go
    get' makes them trivial to install if you need them.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Herbert Fischer at Apr 23, 2013 at 11:57 pm
    Sorry, but I'm still not satisfied.

    Sounds good for a web project in which those format are related, but not
    for all use cases of a image processing library. Isn't Go a systems
    language?

    I pretend to write new image format handlers and probably the best place
    would be the go.image repository, but I think don't having jpeg, png and
    gif together seems a bit messy.

    On 23 April 2013 20:33, Jesse McNelis wrote:

    On 24/04/2013 9:15 AM, "Herbert Fischer" wrote:

    What is the reason for these image formats be in separate repositories?
    Jpeg, PNG, and GIF are very commonly used. Tiff and BMP much less so. 'Go
    get' makes them trivial to install if you need them.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Apr 24, 2013 at 12:01 am
    The images supported by the std lib are the minimum required to run golang.org, everything else lives elsewhere.
    On 24/04/2013, at 9:57, Herbert Fischer wrote:

    Sorry, but I'm still not satisfied.

    Sounds good for a web project in which those format are related, but not for all use cases of a image processing library. Isn't Go a systems language?

    I pretend to write new image format handlers and probably the best place would be the go.image repository, but I think don't having jpeg, png and gif together seems a bit messy.

    On 23 April 2013 20:33, Jesse McNelis wrote:
    On 24/04/2013 9:15 AM, "Herbert Fischer" wrote:

    What is the reason for these image formats be in separate repositories?
    Jpeg, PNG, and GIF are very commonly used. Tiff and BMP much less so. 'Go get' makes them trivial to install if you need them.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Herbert Fischer at Apr 24, 2013 at 11:53 am
    Fair enough but still weird choice. Looks a bit inconsistent.

    On 23 April 2013 21:01, Dave Cheney wrote:

    The images supported by the std lib are the minimum required to run
    golang.org, everything else lives elsewhere.

    On 24/04/2013, at 9:57, Herbert Fischer wrote:

    Sorry, but I'm still not satisfied.

    Sounds good for a web project in which those format are related, but not
    for all use cases of a image processing library. Isn't Go a systems
    language?

    I pretend to write new image format handlers and probably the best place
    would be the go.image repository, but I think don't having jpeg, png and
    gif together seems a bit messy.

    On 23 April 2013 20:33, Jesse McNelis wrote:


    On 24/04/2013 9:15 AM, "Herbert Fischer" <herbert.fischer@gmail.com>
    wrote:
    What is the reason for these image formats be in separate repositories?
    Jpeg, PNG, and GIF are very commonly used. Tiff and BMP much less so. 'Go
    get' makes them trivial to install if you need them.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Apr 24, 2013 at 11:53 am
    How do you propose to reconcile this inconsistency ?

    On Wed, Apr 24, 2013 at 9:52 PM, Herbert Fischer
    wrote:
    Fair enough but still weird choice. Looks a bit inconsistent.

    On 23 April 2013 21:01, Dave Cheney wrote:

    The images supported by the std lib are the minimum required to run
    golang.org, everything else lives elsewhere.

    On 24/04/2013, at 9:57, Herbert Fischer wrote:

    Sorry, but I'm still not satisfied.

    Sounds good for a web project in which those format are related, but not
    for all use cases of a image processing library. Isn't Go a systems
    language?

    I pretend to write new image format handlers and probably the best place
    would be the go.image repository, but I think don't having jpeg, png and gif
    together seems a bit messy.

    On 23 April 2013 20:33, Jesse McNelis wrote:


    On 24/04/2013 9:15 AM, "Herbert Fischer" <herbert.fischer@gmail.com>
    wrote:
    What is the reason for these image formats be in separate repositories?
    Jpeg, PNG, and GIF are very commonly used. Tiff and BMP much less so. 'Go
    get' makes them trivial to install if you need them.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Herbert Fischer at Apr 24, 2013 at 1:32 pm
    Not sure, but I would move all image format subpkgs (and maybe related
    packages - image/color ?) to be in the same place, either stdlib or
    go.image.

    On 24 April 2013 08:53, Dave Cheney wrote:

    How do you propose to reconcile this inconsistency ?

    On Wed, Apr 24, 2013 at 9:52 PM, Herbert Fischer
    wrote:
    Fair enough but still weird choice. Looks a bit inconsistent.

    On 23 April 2013 21:01, Dave Cheney wrote:

    The images supported by the std lib are the minimum required to run
    golang.org, everything else lives elsewhere.

    On 24/04/2013, at 9:57, Herbert Fischer wrote:

    Sorry, but I'm still not satisfied.

    Sounds good for a web project in which those format are related, but not
    for all use cases of a image processing library. Isn't Go a systems
    language?

    I pretend to write new image format handlers and probably the best place
    would be the go.image repository, but I think don't having jpeg, png
    and gif
    together seems a bit messy.

    On 23 April 2013 20:33, Jesse McNelis wrote:


    On 24/04/2013 9:15 AM, "Herbert Fischer" <herbert.fischer@gmail.com>
    wrote:
    What is the reason for these image formats be in separate
    repositories?
    Jpeg, PNG, and GIF are very commonly used. Tiff and BMP much less so.
    'Go
    get' makes them trivial to install if you need them.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Hotei at Apr 24, 2013 at 1:33 pm
    I agree with those that imply it's purely cosmetic - but I'd suggest moving
    tiff and bmp under the images package. There aren't so many image formats
    that clutter is a factor and other than clutter I don't see what the
    downside would be - other than a new gofix rule perhaps.

    Just to be clear I don't think the current system is broken. It's
    definitely workable. Just a tiny bit inconsistent. If the reason things
    are where they are is purely because the folks maintaining golang.org want
    them there that's ok with me. Putting stuff in code.google.com/p/ makes it
    harder to find for newbies and if that's the intent then it seems to be
    working.


    On Wednesday, April 24, 2013 7:53:41 AM UTC-4, Dave Cheney wrote:

    How do you propose to reconcile this inconsistency ?

    On Wed, Apr 24, 2013 at 9:52 PM, Herbert Fischer
    <herbert...@gmail.com <javascript:>> wrote:
    Fair enough but still weird choice. Looks a bit inconsistent.


    On 23 April 2013 21:01, Dave Cheney <da...@cheney.net <javascript:>>
    wrote:
    The images supported by the std lib are the minimum required to run
    golang.org, everything else lives elsewhere.

    On 24/04/2013, at 9:57, Herbert Fischer wrote:

    Sorry, but I'm still not satisfied.

    Sounds good for a web project in which those format are related, but
    not
    for all use cases of a image processing library. Isn't Go a systems
    language?

    I pretend to write new image format handlers and probably the best
    place
    would be the go.image repository, but I think don't having jpeg, png
    and gif
    together seems a bit messy.

    On 23 April 2013 20:33, Jesse McNelis wrote:


    On 24/04/2013 9:15 AM, "Herbert Fischer" <herbert...@gmail.com<javascript:>>
    wrote:
    What is the reason for these image formats be in separate
    repositories?
    Jpeg, PNG, and GIF are very commonly used. Tiff and BMP much less so.
    'Go
    get' makes them trivial to install if you need them.

    --
    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 golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Herbert Fischer at Apr 24, 2013 at 1:45 pm
    Are there some concerns with API size in the stdlib?

    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.
    On 24 April 2013 10:25, Hotei wrote:

    I agree with those that imply it's purely cosmetic - but I'd suggest
    moving tiff and bmp under the images package. There aren't so many image
    formats that clutter is a factor and other than clutter I don't see what
    the downside would be - other than a new gofix rule perhaps.

    Just to be clear I don't think the current system is broken. It's
    definitely workable. Just a tiny bit inconsistent. If the reason things
    are where they are is purely because the folks maintaining golang.orgwant them there that's ok with me. Putting stuff in
    code.google.com/p/ makes it harder to find for newbies and if that's the
    intent then it seems to be working.


    On Wednesday, April 24, 2013 7:53:41 AM UTC-4, Dave Cheney wrote:

    How do you propose to reconcile this inconsistency ?

    On Wed, Apr 24, 2013 at 9:52 PM, Herbert Fischer
    wrote:
    Fair enough but still weird choice. Looks a bit inconsistent.

    On 23 April 2013 21:01, Dave Cheney wrote:

    The images supported by the std lib are the minimum required to run
    golang.org, everything else lives elsewhere.

    On 24/04/2013, at 9:57, Herbert Fischer wrote:

    Sorry, but I'm still not satisfied.

    Sounds good for a web project in which those format are related, but
    not
    for all use cases of a image processing library. Isn't Go a systems
    language?

    I pretend to write new image format handlers and probably the best
    place
    would be the go.image repository, but I think don't having jpeg, png
    and gif
    together seems a bit messy.

    On 23 April 2013 20:33, Jesse McNelis wrote:


    On 24/04/2013 9:15 AM, "Herbert Fischer" <herbert...@gmail.com>
    wrote:
    What is the reason for these image formats be in separate
    repositories?
    Jpeg, PNG, and GIF are very commonly used. Tiff and BMP much less so.
    'Go
    get' makes them trivial to install if you need them.

    --
    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 golang-nuts...@**googlegroups.com.
    For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Apr 24, 2013 at 1:50 pm

    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
    organized?
    the contribution process to sub-repositories is the same as that of the
    main repository.

    Merging back to the main repository means the API must be frozen and no
    incompatible
    API changes will be accepted.

    Considering the current status of the two image packages (tiff and bmp), I
    don't think they
    are ready.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Herbert Fischer at Apr 24, 2013 at 1:56 pm
    The contribution process of those sub-repositories is not documented. At
    least I've found nothing about it.

    But if you say so, I see no problem in moving the entire image API to the
    sub-repo. This could even bring more attention and contributors to this
    repo.
    On 24 April 2013 10:49, minux wrote:


    On Wed, Apr 24, 2013 at 9:39 PM, Herbert Fischer <
    herbert.fischer@gmail.com> 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
    organized?
    the contribution process to sub-repositories is the same as that of the
    main repository.

    Merging back to the main repository means the API must be frozen and no
    incompatible
    API changes will be accepted.

    Considering the current status of the two image packages (tiff and bmp), I
    don't think they
    are ready.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Volker Dobler at Apr 24, 2013 at 2:27 pm

    Am Mittwoch, 24. April 2013 15:55:54 UTC+2 schrieb Herbert Fischer:
    The contribution process of those sub-repositories is not documented. At
    least I've found nothing about it.
    It is the same, even if not advertised in bold copy.

    But if you say so, I see no problem in moving the entire image API to the
    sub-repo. This could even bring more attention and contributors to this
    repo.
    This split is not to annoy users: There are packages with a stable API which
    is guaranteed to be stable for years to come. There must not be major issues
    in this API and people may (and will) rely on this gurantee.
    The sub repos are for stuff which is not (jet) that stable and might evolve
    in a
    backwards incompatible way.

    Moving _all_ image stuff to a sub repo would leave Go without any guaranteed
    stable image processing capabilities. This will hinder wider adoption if Go.

    Some line has to be drawn. Tiff with its many options/versions is awful and
    bmp not that common in web.

    Thus: The most useful image formats are in the standard lib with _
    guaranteed_
    stable API. Everything else is in a sub repo.

    V.



    On 24 April 2013 10:49, minux <minu...@gmail.com <javascript:>> wrote:


    On Wed, Apr 24, 2013 at 9:39 PM, Herbert Fischer <herbert...@gmail.com<javascript:>
    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
    organized?
    the contribution process to sub-repositories is the same as that of the
    main repository.

    Merging back to the main repository means the API must be frozen and no
    incompatible
    API changes will be accepted.

    Considering the current status of the two image packages (tiff and bmp),
    I don't think they
    are ready.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Hotei at Apr 24, 2013 at 2:21 pm
    Minux,
    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.
    On Wednesday, April 24, 2013 9:49:35 AM UTC-4, minux wrote:


    On Wed, Apr 24, 2013 at 9:39 PM, Herbert Fischer <herbert...@gmail.com<javascript:>
    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
    organized?
    the contribution process to sub-repositories is the same as that of the
    main repository.

    Merging back to the main repository means the API must be frozen and no
    incompatible
    API changes will be accepted.

    Considering the current status of the two image packages (tiff and bmp), I
    don't think they
    are ready.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Volker Dobler at Apr 24, 2013 at 2:29 pm

    Am Mittwoch, 24. April 2013 16:21:24 UTC+2 schrieb Hotei:

    Minux,
    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".

    V.


    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
    organized?
    the contribution process to sub-repositories is the same as that of the
    main repository.

    Merging back to the main repository means the API must be frozen and no
    incompatible
    API changes will be accepted.

    Considering the current status of the two image packages (tiff and bmp),
    I don't think they
    are ready.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Hotei at Apr 24, 2013 at 3:11 pm
    Volker,
    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:
    Minux,
    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".

    V.


    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
    organized?
    the contribution process to sub-repositories is the same as that of the
    main repository.

    Merging back to the main repository means the API must be frozen and no
    incompatible
    API changes will be accepted.

    Considering the current status of the two image packages (tiff and bmp),
    I don't think they
    are ready.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Apr 24, 2013 at 12:36 pm

    On Wed, Apr 24, 2013 at 8:01 AM, Dave Cheney wrote:

    The images supported by the std lib are the minimum required to run
    golang.org, everything else lives elsewhere.
    I don't think this is the criteria for inclusion in the std lib (a lot of
    standard packages are not
    needed for golang.org).

    I think tiff is moved to a sub-repository is because tiff is so complex
    that we are not sure
    the current API is suitable for Go 1 (and in fact, we've made at least one
    incompatible API
    change to that package since the move).

    the bmp package is very incomplete (e.g. the decoder doesn't support RLE),
    so it's moved
    to the sub-repository.

    I believe when a package in sub-repository is feature complete and has a
    stable API that
    we're willing to commit to, it will be moved back to std lib.
    On 24/04/2013, at 9:57, Herbert Fischer wrote:

    Sorry, but I'm still not satisfied.

    Sounds good for a web project in which those format are related, but not
    for all use cases of a image processing library. Isn't Go a systems
    language?

    I pretend to write new image format handlers and probably the best place
    would be the go.image repository, but I think don't having jpeg, png and
    gif together seems a bit messy.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Herbert Fischer at Apr 24, 2013 at 1:28 pm
    This is new and makes a bit more sense about the split, but doesn't answer
    how someone would contribute to these image APIs.

    On 24 April 2013 09:35, minux wrote:

    On Wed, Apr 24, 2013 at 8:01 AM, Dave Cheney wrote:

    The images supported by the std lib are the minimum required to run
    golang.org, everything else lives elsewhere.
    I don't think this is the criteria for inclusion in the std lib (a lot of
    standard packages are not
    needed for golang.org).

    I think tiff is moved to a sub-repository is because tiff is so complex
    that we are not sure
    the current API is suitable for Go 1 (and in fact, we've made at least one
    incompatible API
    change to that package since the move).

    the bmp package is very incomplete (e.g. the decoder doesn't support RLE),
    so it's moved
    to the sub-repository.

    I believe when a package in sub-repository is feature complete and has a
    stable API that
    we're willing to commit to, it will be moved back to std lib.
    On 24/04/2013, at 9:57, Herbert Fischer wrote:

    Sorry, but I'm still not satisfied.

    Sounds good for a web project in which those format are related, but not
    for all use cases of a image processing library. Isn't Go a systems
    language?

    I pretend to write new image format handlers and probably the best place
    would be the go.image repository, but I think don't having jpeg, png and
    gif together seems a bit messy.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 23, '13 at 11:15p
activeApr 24, '13 at 3:11p
posts17
users6
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase