strongloop / strong-remoting

Communicate between objects in servers, mobile apps, and other servers.
www.strongloop.com
Other
105 stars 93 forks source link

Support returning a transport agnostic ReadableStream #214

Closed ritch closed 8 years ago

ritch commented 9 years ago

Here is a basic example of what I'd like to be able to do:

function createStream(options, cb) {
  var stream = createReadableObjectStream();
  cb(null, stream);
}

sharedClass.defineMethod('createStream', {
  returns: {
    arg: 'stream',
    type: 'ReadableStream',
    json: true,
    contentType: 'application/json; boundary=NL' // this is the default
  }
});

For adapters that support multiple encodings (http) we would need a way to specify the required info.

/cc @raymondfeng @bajtos

bajtos commented 9 years ago

FWIW, I think this is a duplicate of #35.

For adapters that support multiple encodings (http) we would need a way to specify the required info.

The discussion in #35 has some ideas how this could be implemented.

gausie commented 9 years ago

Will this support setting result headers programmatically?

I currently need to set the name of the file that is being streamed based on model data. I do so by hacking res in as a parameter (using accepts: [ { arg: 'res', type: 'object', http: { source: 'res' } } ]) then using res.setHeader and finally manually piping my stream to res.

Ideally in closing this bug, it would be made possible to achieve this as well!

EDIT: I refactored to use res.attachment(), but the requirement still stands.

ritch commented 9 years ago

@gausie you can do this now by setting a return argument to {http: {target: 'header', header: 'Content-Type': myDynamicContentType}. But I think we can make this a bit better by using the streams encoding property or another property that you can just set on the stream itself (so the function stays transport agnostic).

I'd suggest creating a new issue which explains your use case so others can chime in and we can up the priority.

richardpringle commented 8 years ago

Apparently this issue has a couple of duplicates #35, strongloop/loopback-swagger#34, and strongloop/loopback#2209... and I'm realizing now that it leads to a bit of a wild goose chase. I am going to close this issue in favor of the others and I believe that his issue actually may have been solved already by #216.

Please re-open and mention me directly if there are still concerns!