Closed wsc1 closed 6 years ago
mewmew
commented
6 years ago Seeking follow-up discussion, as the idea of the role of Seeking in the interface hasn't converged.
I still don't have any concrete thoughts on seeking. Have to try something and experiment. I don't think we'll get it right the first time around. Better to iterate on an API when it's still early stages.
wsc1
commented
6 years ago Ok, I'll take that as an OK to merge so others have a chance to play with it at zc.org
Thanks.
On 18 August 2018 at 19:43, Robin Eklind notifications@github.com wrote:
Seeking follow-up discussion, as the idea of the role of Seeking in the interface hasn't converged.
I still don't have any concrete thoughts on seeking. Have to try something and experiment. I don't think we'll get it right the first time around. Better to iterate on an API when it's still early stages.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zikichombo/codec/pull/12#issuecomment-414074782, or mute the thread https://github.com/notifications/unsubscribe-auth/ASR0110EnT529eFWFG1wGVy9bOL8v2N4ks5uSFJAgaJpZM4WCnL8 .
-- Scott Cotton President, IRI France SAS http://www.iri-labs.com
mewmew
commented
6 years ago It would be sweet if we actually had access to the domain name zc.org
This PR adds a SeekingDecoder codec function;
It also hides the Codec.PkgPath, the mechanism that consumers use to control what codec gets used in what case.
Seeking follow-up discussion, as the idea of the role of Seeking in the interface hasn't converged.
Also, the pkgSel mechanism has received no comment. It gives callers full control, requires codec implementations place encoding/decoding functions in one package. This PR enforces moreover that no-one can (easily) hack the package path associated with a codec.
Comments/thoughts appreciated.