b)
Remember the sys/util situation in 0.8?
>1. What is the cost of keeping "sys" throwing?
>2. What is the cost of putting it back?
This is a different type of change entirely but I think the general
idea of the questions is still applicable:
1. What is the cost of this change being made as soon as 0.10 when
the crypto API is currently marked as stable in 0.8?
2. What is the cost of marking the crypto API as unstable for 0.10,
then making the change in 0.12?
With the sys/util situation, the concern was that the 'increased
difficulty of migrating code' could be harmful to the project from a
long term perspective, including the possibility of it injuring
node's credibility in the "no, it'll work, trust me" sense.
If the labels for stability of node's core modules aren't respected,
aren't we sort of in the same situation?
Cost of 1 is it might break a bunch of peoples modules even though
the API was marked as stable. I guess these people should have
subscribed to the mailing list.
I don't know of any cost to 2, just the benefit of giving people
notice that the API is unstable again so they should expect
potential module breakage on the next version.
I like the idea of stuff changing for the better as quickly as
possible as much as the next person here, but I think being
consistent with breaking API changes is more important.
On Oct 8, 7:24 pm, Isaac Schlueter <
i...@izs.me> wrote:
> Currently, the crypto module defaults to using 'binary' encoded
> strings everywhere as the default input and output encoding.
>
> This is problematic for a few reasons:
>
> 1. It's slower than necessary.
> 2. It doesn't match the rest of Node.
>
> The reason for this is that crypto predates Buffers, and no one ever
> bothered to go through and change it. (The same reason it's got some
> odd hodgepodge of update/digest methods vs the Stream interface you
> see everywhere else in node.)
>
> The reason it persists in 0.8 (and perhaps in 0.10) is that we
> (perhaps overly optimistically) labelled that API "stable", and don't
> want to break anyone's programs. It's going to change eventually to
> match the rest of node. The only question is whether the change will
> come in 0.10 or 0.12. A stream interface to all the crypto classes is
> coming in 0.10; using 'binary' strings by default is thus even more
> obviously a departure from the rest of node.
>
> Note that, if you only use crypto for hashes, and set the 'hex'
> encoding, then it won't affect you. If you only ever pass the output
> of one crypto function to the input of another (sign/verify, for
> example) then it also won't affect you; you'll just pass buffers
> around instead of binary strings.
>
> Please select one, and reply with your choice and perhaps any other
> feedback you have on this issue. Thanks.
>