osher

Did you see Kevin's answer and question to you? https://github.com/kevinswiber/pipeworks/pull/10#issuecomment-257407502

I think that pipe fittings are implementation details of API, and in the end of it we should adhere to how API look from the outside and the common practices...

clear. I'm right behind you. On Tue, Sep 27, 2016 at 6:58 PM, Scott Ganyo [email protected] wrote: > Yes, I think that's a good point. That's actually why I marked...

**Edited**: fixed wordings... To do this we need to guarantee order of operations in pipe-finding: - named pipe exists in memory? - yes - use it. - no: - load...

if you would insist to include this fitting as part of your core - perhaps you would like to consider moving `mustache` to optional dependencies or peer dependencies.

on second thought, looks like `mustache` is your smaller problem... https://github.com/apigee-127/bagpipes/issues/16

``` pipes:content output (context[result]): undefined +3ms ``` sure it's `undefined`. the output is in another attribute (`result`), named in `fittingDef.output` ([seen here](https://github.com/apigee-127/bagpipes/blob/master/lib/bagpipes.js#L212) + the `if` sttmt that comes after) I...

IMHO, when a request is mapped to a swagger-operation - it should not leave the pipe without emitting a response. Am I missing something? Can you think of a case...

@chrisegner - if you say that with a shorter yaml it works while with a heavier yaml it doesnt - it's a score for the buffer theory. I know that...

@chrisegner - man, I need help to reproduce. I've constructed an e2e test with a huge doc (over 100K), and did not encounter the bug. can you please help provide...