Support streaming

[dcousens]

No description provided.

[dcousens]

Ref browserify/sha.js#25

[jprichardson]

According to what you've said previously, shouldn't streaming be in a new module? This way those who don't need it can just use the function in ripemd160, but those that do could call ripemd160-streaming? Then ripemd160-streaming could include ripemd160.

[dcousens]

Unfortunately, it is integral to the block padding which is currently done in https://github.com/crypto-browserify/ripemd160/blob/master/lib/ripemd160.js#L173-L208.

Granted, we could do what is done by createHash and instead just delay the call to the ripemd160 until the digest, but, that isn't really supporting streaming, thats just deferred execution with unnecessary storage of all the data. Aka, not streaming.

[jprichardson]

So you're stating that it's not possible to have two separate modules i.e. it's not possible to have ripemd160-streaming that includes ripemd160?

[dcousens]

@jprichardson well, we could have two modules. But this module as it stands would be abandoned [by crypto-browserify] because ripemd160-streaming is what we would use for the ripemd160 drop in.
No reason this module can't live on otherwise though.

it's not possible to have ripemd160-streaming that includes ripemd160?

It's certainly possible to put it in the exports, but, it serves no purpose to crypto-browserify, as we can't use it (except in the way it is currently being used, which, obviously, would be superseded by ripemd160-streaming).

[fanatid]

we could create module that contain ripemd160 primitives (block handler and padding creator) -- ripemd160-primitives for example, then use this primitives in ripemd160-1shot and current ripemd160 (supports streams and based on hash-base)
but I think it's too overhead %) so, why not just stay with version with streams...?

[fanatid]

streams are supported with hash-base