Yeah, currently it's not optimal, but working on it 🙂

the problem is that the api i am trying to use sends blobs of json as multipart whenever a message comes from chat

and i have no idea how to keep listening and not closing the stream

its a very narrow usecase and definitly weird choice for them to make it behave like this

That does sound weird :/

its a go library.. maybe it was the "easiest" to implement in a stupid system

In Go everything is a Stream and it's easy to keep a stream open, but in HTTP/1.1 as far as I know, other than stay-alive, you're not actually supposed to to do a "stream of uploads, other than a chunked upload"./

in pure java i can do it but the code gets real ugly real fast

also hard to reason about etc

or rather.. pure java stdlib implementation written with kotlin syntax, looks just slightly less ugly because of

.use { }

Well that turned out to be way more work than just making the headers case-insensitive XD

@Nikky @Derk-Jan Karrenbeld hey, been reading this and feel appreciated to have 2 of you working on issues 😄

👍

Does anybody have thoughts on my proposed solutions for handling large downloads? https://github.com/kittinunf/Fuel/issues/414#issuecomment-431477130

I think that you shouldn't worry too much about API changes, as long as they're isolated to a single functionality. One of my ideas is to change request to have .upload and .download give back a wrapper (delegates to

Request

) that has extra functionality. That would also be a breaking API change. That said: I ám working on a generic stream in stream out approach that might work well in conjunction with number 3 and 2. It does nót get rid of .data, but by default give you the stream, as you propose, and only if you use .data it gets loaded into memory. Number 1 and 4 are a no for me. 1 breaks expectations, 4 is meh because we all agree this is an issue.

Is your stream in/stream out approach in a public fork?

Haven't pushed it yet, I can soon (am at the office right now)

But please chip in ideas or PR if you have a better idea! My stream approach just allows you to write ANYTHING to body as long as it is a stream 🙂 (and read from body as a stream, to anything that is a stream, such as a FileWriter)

I don’t think we should do nothing either, let’s fix it

I would say that i am leaning on 2 at the moment, unless @Derk-Jan Karrenbeld has a better idea on this.

@sbyrne can you eloborate on Con a bit more? because i didn’t get the “Have to make Result open” part though

Result

is final. To override

Result.dataStream

it needs to be open.

Yeah it shouldn't be I think. Request is also not

final

.

Once @Derk-Jan Karrenbeld's PR is up, I'll rebase my approach #2 on it.

ah … that is unfortunate though because it breaks

Result

in the process …

Because for

Result

it needs to be final?

A way around that is to add a property that returns the stream, and make that open.

so a content holder ?

feels slightly convoluted but still better than the alternatives

Has anybody successfully used

Request.source( (Request,URL)->File ):Request

?