Would like to start working on this issue.
The package I am planning to use for this is sse by the Dart Team.

Would update with the initial draft of the design sketch in sometime.

P.S. I am looking forward to following the same approach as in #258 and #215, hence would love to get some feedback on them!

Sure @mmjsmohit.

Here's the proposed the design sketch.

Hi I was looking around for a package to support SSE but the flutter_client_sse No Web Support doesn't support web. The package mentioned by mmjsmohit sse is a dart team package and doesn't support flutter web either.
And there's another package event_source that doesn't work on web aswell.
Another interesting thread dart-lang/http#337

I guess we either need to implement our own. Or use conditional imports

@WrathOP API Dash is only supported for the following platforms:
macOS, Windows, Linux, Android, iOS
We never had web support and adding it will require a lot of heavy lifting because it will require a proxy server in the middle to perform all requests and just display results on the browser.

Here's the proposed the design sketch.

Do we make sse a seperate APIType or just handle it in the http type when the header contains text/event-stream and we just keep the connection alive and showing the list of all the events incoming.

Here's the proposed the design sketch.

Untitled-2024-02-22-0219 (2)

The image is not opening. Please drag and drop it properly in the comments.

Do we make sse a seperate APIType or just handle it in the http type when the header contains text/event-stream and we just keep the connection alive and showing the list of all the events incoming.

text/event-stream in the header helps identify the request as an SSE, but the whole catch is how can you obtain the header before you start receiving the response content. If we know the API Type before hand we can handle response accordingly.

1. Replied above
2. http also has a streamed response feature you can check it out. flutter_client_sse is built on top of http. There is also https://pub.dev/packages/sse

Here's the proposed the design sketch.

Untitled-2024-02-22-0219 (2)

The image is not opening. Please drag and drop it properly in the comments.

Do we make sse a seperate APIType or just handle it in the http type when the header contains text/event-stream and we just keep the connection alive and showing the list of all the events incoming.

text/event-stream in the header helps identify the request as an SSE, but the whole catch is how can you obtain the header before you start receiving the response content. If we know the API Type before hand we can handle response accordingly.

1. Replied above 2. http also has a streamed response feature you can check it out. flutter_client_sse is built on top of http. There is also https://pub.dev/packages/sse

It was the same image from above.

Ok The fact that user can use normal http and still receive a text/event-stream do we then switch him to sse type of api? or we just throw an error ? or just return the first event and close the stream?

I was thinking of using http package with streamedResponse only and that sse package is build for a specification of a backend and frontend only and not a general propose package.

So finally we are making a different api type and doing it that way not based on the response headers.

Ok The fact that user can use normal http and still receive a text/event-stream do we then switch him to sse type of api? or we just throw an error ? or just return the first event and close the stream?

In this case whatever is the default behaviour of http get/post/etc. will happen. Will require no changes in API Dash.
User will not be forced to switch to SSE type.

I was thinking of using http package with streamedResponse only and that sse package is build for a specification of a backend and frontend only and not a general propose package.

ok. take your call what is best for the project.

So finally we are making a different api type and doing it that way not based on the response headers.

cool

@ashitaprasad can i work on this issue with the same ui layout .
I was thinking about checking for text/event-stream header and then listen to the stream using the http client. Would this be sufficient ? I read your comment above about trying to obtain the header before getting responses , but that wouldn't be hard right since sse is initiated only after getting the header. Also is it okay to use this on existing api type http rather than creating new one exclusively for sse(I have to look into if its possible,if under some condition something goes wrong we can make another apitype ) . The current http response model can be tweeked to handle this . Like adding a list for containing the streamed message s .

Sure @Clasherzz. You can try out your approach and check if it works.

@ashitaprasad the streamed reponse doesn't have acces to request headers unlike normal response. This is true for other sse related packages based on http. So it would be hard for users to get the headers that client adds automatically . We can use http_interceptor(haven't tried it until now) . Or go with dio based packages . For the proposal i am going to go with the http_interceptor.
If there are anyother methods pleae do let me know in the mean time

@ashitaprasad the streamed reponse doesn't have acces to request headers unlike normal response. This is true for other sse related packages based on http. So it would be hard for users to get the headers that client adds automatically . We can use http_interceptor(haven't tried it until now) . Or go with dio based packages . For the proposal i am going to go with the http_interceptor. If there are anyother methods pleae do let me know in the mean time

In the comment above (#116 (comment)) @ashitaprasad already specified that it will be difficult to determine whether to switch to SSE and stream the response. Hence, the best approach is to let user choose SSE, perform request and stream the response accordingly.

@animator yes but i am not referring to that . What i mean is that in current http_client after getting response it displays the request headers from the response . This helps to show the headers that where added by the package like user agent and encodings. In streamed Response you can't get that . To overcome it i have to use http_interceptor. I am going with the approach as you have told as my suggested approach failed

@ashitaprasad @animator I have went through many documentations of sse but didnt find anything related to the Request types that SSE can have. I found GET and POST SSE. In my current i have made it available for all.
Also is it a good idea to notify the user if the reponse header doesn't contain text/event-stream if an SSE Request is made. Currently I am not checking the response headers.

@animator yes but i am not referring to that . What i mean is that in current http_client after getting response it displays the request headers from the response . This helps to show the headers that where added by the package like user agent and encodings. In streamed Response you can't get that . To overcome it i have to use http_interceptor. I am going with the approach as you have told as my suggested approach failed

Great we are on the same page.

@ashitaprasad @animator I have went through many documentations of sse but didnt find anything related to the Request types that SSE can have. I found GET and POST SSE. In my current i have made it available for all. Also is it a good idea to notify the user if the reponse header doesn't contain text/event-stream if an SSE Request is made. Currently I am not checking the response headers.

Sure will review it. Thanks

PR videos provided by @Clasherzz