Re: [elm-discuss] Re: Implementing websocket-based protocol - lessons learned
Le 23/05/2017 à 18:13, 'Rupert Smith' via Elm Discuss a écrit : > On Tuesday, May 23, 2017 at 3:30:44 PM UTC+1, Christophe de Vienne wrote: > > It is what I did at first, but it has serious drawbacks. The biggest > was > that a subscription implies an update of the Nats state... so I had to > push the state to all the update functions and they had to sent it > back... Very messy. > > > This use case can be catered for by using a correlation id, I think. > Also, perhaps the word 'subscription' is getting overloaded here, you > have the Elm Sub(scription), and the NATS protocol subscription, and the > middleware subscription (listen), making this conversation a little > difficult to nail down... > > == Module Consuming the NATS Protocol > > Elmq.sendString "subscribe" "nats0" > Elmq.listen "nats0" > Except that sending a command to initialize a subscription is not something I want the final module to do. No more that having to send a command to unsubscribe. My current implementation allow the module consuming to simply do: Nats.subscribe "subject" tagger Used this way elmq does not improve the situation. > == The module implementing the NATS protocol > > type Msg = > NewNatsSubscription String > | ... > > Elmq.listenString "subscribe" (\channel -> NewNatsSubscription) > Elm.send channelName ... > > == > > So I sent a subscription request to Nats, and when Nats processed it, it > sends back messages on the named channel. The channel name is used as a > correlation id to link together the act of creating the subscription and > the messages that then flow over that subscription. > > I don't know the specific of NATS and whether it has named channels etc. > but hopefully you get what I am on about? I think I do, and it would work. But the resulting API is less natural that what I achieved already without elmq (unless I am still missing something of course). For sending pure commands though (publish and... that's it I guess, because request requires to handle a response, which elmq won't make easy), elmq could make things better, as the update functions would return only Cmd and not both a Cmd and a Nats.Cmd.Cmd as they have to do right now. That said once the boilerplate is in place, it is not that painful. In the app I am building on top of elm-nats I even added a wrapper type around Cmd and Nats.Cmd.Cmd: type MyCmd msg = PCmd (Cmd msg) | NCmd (Nats.Cmd.Cmd msg) along with batch, map and none functions. All the update functions returns (Model, MyCmd), and the top-level update separates the Cmd from the Nats.Cmd.Cmd and converts the Nats.Cmd.Cmd and Nats.Sub.Sub to Cmd with the Nats API (which updates the nats state at the same time). -- Christophe de Vienne -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Implementing websocket-based protocol - lessons learned
On Tuesday, May 23, 2017 at 3:30:44 PM UTC+1, Christophe de Vienne wrote: > > It is what I did at first, but it has serious drawbacks. The biggest was > that a subscription implies an update of the Nats state... so I had to > push the state to all the update functions and they had to sent it > back... Very messy. > This use case can be catered for by using a correlation id, I think. Also, perhaps the word 'subscription' is getting overloaded here, you have the Elm Sub(scription), and the NATS protocol subscription, and the middleware subscription (listen), making this conversation a little difficult to nail down... == Module Consuming the NATS Protocol Elmq.sendString "subscribe" "nats0" Elmq.listen "nats0" == The module implementing the NATS protocol type Msg = NewNatsSubscription String | ... Elmq.listenString "subscribe" (\channel -> NewNatsSubscription) Elm.send channelName ... == So I sent a subscription request to Nats, and when Nats processed it, it sends back messages on the named channel. The channel name is used as a correlation id to link together the act of creating the subscription and the messages that then flow over that subscription. I don't know the specific of NATS and whether it has named channels etc. but hopefully you get what I am on about? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Implementing websocket-based protocol - lessons learned
Le 23/05/2017 à 16:23, 'Rupert Smith' via Elm Discuss a écrit : > On Tuesday, May 23, 2017 at 3:04:01 PM UTC+1, Christophe de Vienne wrote: > > A discussion around a concept of "middleware", able to define its own > Cmd and Sub that it could rewrite along with updating its own state > (which can be a part of the app model), would be interesting. > > Cmd and Sub are pretty opaque beasts from where I stand, may be we can > already do such a thing. > > > There are modules that build their own subscriptions, for example: > > http://package.elm-lang.org/packages/mdgriffith/elm-style-animation/3.5.5/Animation > > provides a function to build a subscription. This is just a convenience > function; under the covers the animations are being iterated as a timer > ticks, so the real Sub being created is a timer one. > > So I think if you can define what flexible 'command' and 'subscription' > constructor functions you think the middleware needs, and we can try and > map those down to the simplest Cmd and Sub implementations that cover > all the needed use cases, then that gives us what we would need to > implement in an effects module. Essentially, it would be a messaging > kernel that is flexible enough that any reasonable messaging application > you like can be built on top of it. It is what I did at first, but it has serious drawbacks. The biggest was that a subscription implies an update of the Nats state... so I had to push the state to all the update functions and they had to sent it back... Very messy. The final API I have, although it has some boilerplate, is a lot nicer. -- Christophe de Vienne -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Implementing websocket-based protocol - lessons learned
On Tuesday, May 23, 2017 at 3:04:01 PM UTC+1, Christophe de Vienne wrote: > > A discussion around a concept of "middleware", able to define its own > Cmd and Sub that it could rewrite along with updating its own state > (which can be a part of the app model), would be interesting. > > Cmd and Sub are pretty opaque beasts from where I stand, may be we can > already do such a thing. > There are modules that build their own subscriptions, for example: http://package.elm-lang.org/packages/mdgriffith/elm-style-animation/3.5.5/Animation provides a function to build a subscription. This is just a convenience function; under the covers the animations are being iterated as a timer ticks, so the real Sub being created is a timer one. So I think if you can define what flexible 'command' and 'subscription' constructor functions you think the middleware needs, and we can try and map those down to the simplest Cmd and Sub implementations that cover all the needed use cases, then that gives us what we would need to implement in an effects module. Essentially, it would be a messaging kernel that is flexible enough that any reasonable messaging application you like can be built on top of it. I once had a great job, which was to be paid to work on an open source implementation of the AMQP protocol (Apache Qpid). In Java land the messaging API is called JMS, and it is just what I described above - a messaging API (and implied kernel) that is generic enough to fit most reasonable middleware needs and implementations. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Implementing websocket-based protocol - lessons learned
On Tuesday, May 23, 2017 at 3:06:29 PM UTC+1, Rupert Smith wrote: > > There was someone else who wrote a 'middleware' component for Elm, but did > it with 'out messages' instead of as an effect module. There was a routing > part that you put in you top-level update function. Let me see if I can > find it... > This: https://groups.google.com/forum/#!searchin/elm-discuss/messaging%7Csort:relevance/elm-discuss/gSkvCgTj4q0/TJJCtcX9BgAJ https://github.com/RJWoodhead/elm-memo -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Implementing websocket-based protocol - lessons learned
On Tuesday, May 23, 2017 at 2:50:05 PM UTC+1, Rupert Smith wrote: > > I'm going to the upcoming Elm Europe conference, so I can talk to the core > devs there and see what they think of it. As I said before, perhaps its not > an 'architectural' direction that they like; on the other hand it does seem > both simple and useful. > There was someone else who wrote a 'middleware' component for Elm, but did it with 'out messages' instead of as an effect module. There was a routing part that you put in you top-level update function. Let me see if I can find it... One criticism of elmq might be that it is not so transparent. So if a module sends a message, the Cmd for that is passed into the Elm kernel, and from then on it sort of disappears from the compilers view - the messages are untyped in so far as that they are Json.Encode.Values. There is no way for the compiler to check that whatever receives them has a matching type, or indeed that there is any receiver listening at all. At least with 'out messages' the type checking will flow across the modules. Of course there could still be a bug in code where the 'out messages' are ignored and not processed. It may be possible to improve the elmq API to mitigate these issues - for example, an option to discard messages when there is no receiver and so on. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Implementing websocket-based protocol - lessons learned
Hi Le 23/05/2017 à 15:50, 'Rupert Smith' via Elm Discuss a écrit : > On Monday, May 22, 2017 at 4:08:13 PM UTC+1, Christophe de Vienne wrote: > > I will make some tests with now that the plain version is working > properly. > > > Would be interesting to see if elmq has enough features to support your > use case, or if it needs some extension. I think gathering use cases, > reviewing what other language do and so on is the work that needs to be > done prior to proposing adding it as a supported effects module. Also, > nice that you did it without an effects module, as that is one more > example to compare the code with/without elmq, if you were to redo it on > top of elmq. I hope I am wrong but I do not think I can achieve a natural subscription API on top of elmq. I cannot work on it right now but will. > > I'm going to the upcoming Elm Europe conference, so I can talk to the > core devs there and see what they think of it. As I said before, perhaps > its not an 'architectural' direction that they like; on the other hand > it does seem both simple and useful. A discussion around a concept of "middleware", able to define its own Cmd and Sub that it could rewrite along with updating its own state (which can be a part of the app model), would be interesting. Cmd and Sub are pretty opaque beasts from where I stand, may be we can already do such a thing. -- Christophe de Vienne -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Implementing websocket-based protocol - lessons learned
On Monday, May 22, 2017 at 4:08:13 PM UTC+1, Christophe de Vienne wrote: > > I should have had a better look at what elmq allowed indeed. > > That said until elmq (or something equivalent) is published on > package.elm-lang.org, we get a non-publishable package. > Yes, it would make your package non-publishable too. > I will make some tests with now that the plain version is working > properly. > Would be interesting to see if elmq has enough features to support your use case, or if it needs some extension. I think gathering use cases, reviewing what other language do and so on is the work that needs to be done prior to proposing adding it as a supported effects module. Also, nice that you did it without an effects module, as that is one more example to compare the code with/without elmq, if you were to redo it on top of elmq. I'm going to the upcoming Elm Europe conference, so I can talk to the core devs there and see what they think of it. As I said before, perhaps its not an 'architectural' direction that they like; on the other hand it does seem both simple and useful. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
