Conversation
|
What I thought when I read
|
|
Haha let's hope for none of this. |
|
Awesomesauce @nginnever :) Just to confirm, are you are top of converting the |
|
@diasdavid yeah so this PR will update with the exporter. |
| }) | ||
| }) | ||
|
|
||
| it('returns a stream', (done) => { |
| }).code(500) | ||
| } | ||
| stream.on('data', (data) => { | ||
| return reply(data.stream) |
There was a problem hiding this comment.
This could lead to strange issues when multiple events are emitted from the stream.
There was a problem hiding this comment.
I think this will be okay. The exporter stream in object mode only emits one data event per file. And cat can only request one file to my knowledge. If we allow at some point for cat to take multiple hashs and return multiple file objects then we could have a problem with this. Thoughts?
There was a problem hiding this comment.
It probably will be okay, but I think @dignifiedquire's point was about approaching the mechanism defensively: just because today we can reason out that this should never happen doesn't mean future changes by future authors will always know+remember to hold this requirement. "It's a stream after all, and you can have many data events on streams.."
|
this will need PR to be merged |
| res.on('file', (data) => { | ||
| res.on('data', (data) => { | ||
| data.stream.pipe(process.stdout) | ||
| }) |
There was a problem hiding this comment.
I believe this console.log should not be here and the if (res) is not necessary.
|
I think @dignifiedquire had an unresolved line comment on this? |
5 participants
This is currently using the unixfs-engine event emitter but will be switching to a full duplex stream in the
unixfs-engine.exportersoon