Feature/streaming take2 #79
Conversation
# Conflicts: # core/src/main/scala/Response.scala
And have them use a higher level api at the same time
# Conflicts: # core/src/main/scala/Server.scala # core/src/main/scala/package.scala
# Conflicts: # core/src/main/scala/package.scala
…weak typing The server, of course, did not know how it would be able to serialize Any in order to send the response back
Although there might still be an time complexity issue.
# Conflicts: # core/src/main/scala/Remote.scala # core/src/main/scala/package.scala
# Conflicts: # core/src/main/scala/Server.scala
# Conflicts: # core/src/main/scala/Server.scala
Download Streaming now works
null was being used to act as a placeholder for a stream on the server during deserialization which did not play well with Remote.toString and monitoring
# Conflicts: # core/src/main/scala/package.scala
jedesah
force-pushed
the
feature/streaming_take2
branch
from
eb45278 to
3987183
Compare
|
@jedesah How is your work going with this one? :-) |
|
@ahjohannessen It's coming along well. I would say that it is probably (could have more tests) quite usable but I have a few finishing touches to make before asking the others to re-review and merge. Do you have a solid use case for Remotely Streams? If so, I could try and get it in sooner than later. And also, we might not be using it quite as soon as we thought, but of course I would be glad to help you work through any real world issues you might encounter. |
|
@jedesah Nice to hear :) One of the use-cases I have in mind is to use it in conjunction with akka-persistence and expose selected "changes" as named streams for read-model applications / "reactors" to be able to use catch-up / live stream subscriptions of events. Even though remotely can provide me with streaming I'll probably hard-couple the read-model application part directly to protobuf definitions that live in a separate app-protocol-xyz published jar and have the read-model layer sql updating code directly rely on protobuf generated case classes (scalapb) in order to save time and typing. However, Remotely will play a central role wrt streaming when external applications need to catch up on event streams, here scodec and remotely are a good fit for a selected streams API :) Btw, I am using EventStore for akka-persistence and that makes it a bit easier to have the read-model get events directly from the journal. So it is not critical to me that streaming functionality gets into remotely ASAP, because I can work around that for a while. But it is darn cool to get that kind of functionality into remotely :) |
Add comment to explain why ignoring test failure for now. We should think about the behavior we want here.
|
@jedesah Scalaz 7.1.3 is available now, see https://github.com/scalaz/scalaz/wiki/7.1.3 |
|
@ahjohannessen Sorry for the delay on getting this PR merged. I have been busy with other things, but luckily still related to Streaming so it's helped me adopt some new perspectives on the matter. The PR is in a state where it could potentially be merged, what I was still working on was support for multiple input streams, i.e. In the meantime though I have started using http4s for websocket streaming. They use quite a different API for implementing a streaming server then the one we adopted here. The two approaches would appear to have their own trade offs. Long story short, with the current model for streaming in Remotely, it could prove difficult to implement a chat server. I opened an issue on http4s. As potentially one of the first users of Remotely Streaming, I would be very interested to hear your opinion on the matter. I think it would be ideal if both Remotely and http4s used whichever model proved to be superior. |
|
@jedesah The primary use case I had in mind is just a single stream pr. function, e.g. for notifications or shipping events from an event stream across two systems. |
jedesah
force-pushed
the
feature/streaming_take2
branch
from
b263562 to
31a1312
Compare
|
I added a chat server example using the current streaming model. One could argue that it has some "issues" because it requires the use of a The problem is extremely similar if not exactly the same as the one encountered in http4s for websocket support. As mentioned previously, discussion over this occurred here. I think we should have a discussion to establish what is the best solution. Ideally we can either convince http4s to adopt wtv model we deem superior or adopt their model. It would be somewhat of a shame if we did not adopt the same model unless there is some fundamental difference I am unaware of. |
|
@jedesah this looks great. couple of questions. How are you handling connection loss? Are there any semantics for retrying a request? |
No description provided.