Re: [elm-discuss] Support for binary data
Our use-case: We connect our elm application to a NATS server through a websocket [1] The protocol is text-based but the payload can be binary. We would like to switch to protobuf to encode our payloads but cannot do that because of the elm client. So we stick to json for now. So the need is to be able to encode/decode data structures to a binary websocket connection. [1] https://github.com/orus-io/elm-nats Le 19/07/2017 à 04:34, Martin Bailey a écrit : > What kind of interaction with binary data would you require for your > projects? > > -Blob : black box to store and pass opaque data around (anything that > isn't a valid Unicode string) > -Byte array : equivalent to char/string for arbitrary bytes > -Bit stream : more flexible mechanism to implement binary protocols or > binary coding > > Byte array would remove the need for blobs and would also allow building > a clean bitstream library in pure Elm. It needs to be designed properly > for binary data to be reliable and fun to work with, but that would > probably be the best abstraction. Haskell calls theirs Data.ByteString. > > On Tuesday, July 18, 2017 at 3:10:33 AM UTC-4, Zachary Kessin wrote: > > I would really like to have a way to do file uploads in Elm, I > needed that at a project a while back > > Zach > ᐧ > > On Wed, Jul 12, 2017 at 8:18 PM, Coury Ditch <cmd...@gmail.com > > wrote: > > Here are a couple relevant repos so far - they are mostly barren > at the moment, as we're trying to solve some hard API problems > before we put too much code down. > > https://github.com/cmditch/elm-web3 > <https://github.com/cmditch/elm-web3> > https://github.com/cmditch/elm-truffle-webpack > <https://github.com/cmditch/elm-truffle-webpack> > > > On Sunday, July 9, 2017 at 9:49:46 AM UTC-6, Berry Groenendijk > wrote: > > Coury, > > I am very interested in an Elm version of web3.js. For > exactly the reason you mentioned. Where can I follow the > progress on this project? > > Berry > > Op zaterdag 8 juli 2017 21:30:53 UTC+2 schreef Coury Ditch: > > Our use case: Pure elm library for cryptographic functions. > > We are creating a pure Elm web3.js equivalent. We think > Ethereum developers and the blockchain developer > community at large would benefit from the strong > guarantees of using Elm. > > Thanks > > On Monday, January 11, 2016 at 5:32:43 PM UTC-7, Evan wrote: > > I have been drafting Blob and ArrayBuffer APIs, but > I wasn't sure who needed them. > > What is your particular use case? > > On Mon, Jan 11, 2016 at 4:55 AM, John Watson > <john@gmx.co.uk> wrote: > > Can anyone tell me what the plans are for > supporting binary data in elm? I'm thinking of > a Byte (and some sort of Byte Array) type and > also implementing Blob in HTTP responses. > > -- > 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...@googlegroups.com. > For more options, visit > https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > 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...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > > > -- > Zach Kessin > Teaching Web Developers to test code to find more bugs in less time > Skype: zachkessin > +972 54 234 3956 / +44 203 734 9790 / +1 617 778 7213 > > -- > 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...@go
Re: [elm-discuss] Re: Can we get a patch release of elm-lang/core?
I think the idea is to embed the fixed version of the function in your code and use it instead of the core one. Once elm 0.19 is out you can remove it and change back to using the core implementation. Le 30 juillet 2017 20:20:49 GMT+02:00, Filip Haglund <fille.hagl...@gmail.com> a écrit : >I need all users of my package to have the bugfix as well. It's a part >of >elm-test, so if I'm testing code that depends on the buggy version of >core >against my fixed version, it will of course fail. > >On Sunday, July 30, 2017 at 3:13:48 PM UTC+2, Filip Haglund wrote: >> >> I'm currently blocked on this bug >> >https://github.com/elm-lang/core/commit/8e885c9bd4a7556ee039e2f53bbb3a1555d0243e#diff-de88ec52111a9d7bd82177e4654bb0f0R449 > >> . It's been fixed months ago, but there's no patch release available. > >> >> Is 6.0.0 very close to being released, or can I get a patch release >for >> this bug? :) >> > >-- >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. -- Christophe de Vienne (envoyé de mon mobile) -- 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] Systemic problem in Object Oriented languages
Le 20/07/2017 à 12:15, Peter Damoc a écrit : > > > On Thu, Jul 20, 2017 at 12:49 PM, Christophe de Vienne > <christo...@cdevienne.info <mailto:christo...@cdevienne.info>> wrote: > > > Well, it is more an intuition after more than 20 years of coding that an > elaborated opinion. > > But the first thing that comes to my mind is the resulting complexity, > and often confusion. I find that having a clean separation between data > & logic makes things a lot cleaner, easier to understand and maintain. > > I do realize I would need to elaborate a little more to be convincing on > this, but so far it is all I got :-) > > > Out of curiosity, are you keeping your Model, update and view in > separate modules? At first no, then depending on how much of the module I want to reuse, I separate them. In the end, I have reusable models as submodules of a "Data" module, a few model+update modules (mainly for the session data, which has no global view), and the rest are single modules with model+update+view (for pages mainly, and a few subcomponents). It is in great part inspired by the SPA example from Richard Feldman: https://github.com/rtfeldman/elm-spa-example -- 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] Systemic problem in Object Oriented languages
Le 20/07/2017 à 11:12, Dave Ford a écrit : > Now, is it actually a systemic problem ? My intuition is that it is the > root of many difficulties OO languages can have, even though it does not > seem like a problem at first. > > > Can you give an example? Specifically, without confusing the unrelated > issue of immutability? > Well, it is more an intuition after more than 20 years of coding that an elaborated opinion. But the first thing that comes to my mind is the resulting complexity, and often confusion. I find that having a clean separation between data & logic makes things a lot cleaner, easier to understand and maintain. I do realize I would need to elaborate a little more to be convincing on this, but so far it is all I got :-) -- 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] Systemic problem in Object Oriented languages
Regardless of immutability, saying "this" imply a bound between the data and the function, which is the very thing Elm wants to avoid. So I think the systemic problem referred to here is "separation of data and logic", and its incarnation (sort of) is the ability to say "this". Now, is it actually a systemic problem ? My intuition is that it is the root of many difficulties OO languages can have, even though it does not seem like a problem at first. Le 20/07/2017 à 09:55, Dave Ford a écrit : > There is a line from the docs that I am trying to understand: "Elm > encourages a strict separation of data and logic, and the ability to > say |this| is primarily used to break this separation. This is a > systemic problem in Object Oriented languages that Elm is purposely > avoiding." > > What is the systemic problem being reference? Is it the [lack of] > "separation of data and logic" or "the ability to say this"? > > I have been programming in Java (an OO language) for a long time. I can > name dozens of systemic problems in the language. But the ability to say > "this" is not one of them. Nor is it the commingling of data and logic. > > Please help me to understand what the author is talking about. > > Thanks. > > Side note: "this" /is/ a problem in JavaScript. But not in OO generally. > > -- > 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 > <mailto:elm-discuss+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout. -- 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
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: Best practices to create examples for an elm package?
Le 23/05/2017 à 17:44, 'Rupert Smith' via Elm Discuss a écrit : > On Monday, May 8, 2017 at 3:38:55 PM UTC+1, Eirik Sletteberg wrote: > > Maybe write an example in the form of an integration test - then you > know your example will be up to date with the actual code, and it > may even discover bugs! > > > I think there is an issue here that did not come up for discussion yet: > > Suppose I have some examples or some tests, and those need packages that > the actual library does not use. Those packages get sucked in as > dependencies even though the library itself does not use them? > > Is there a way to have tests or examples and for those to use extra > packages, but for those packages not to be included as transitive > dependencies of the library itself? For the example I have a separate 'elm-package.json' in the 'example' directory, and it has '../src', '.' as source-directory. About test, with elm-tests you also have a separate elm-package.json in tests/. -- 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
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
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.
[elm-discuss] Implementing websocket-based protocol - lessons learned
Hi everyone, Last week I coded a NATS [1] client, which is a PUB/SUB messaging system, in Elm [2]. It was very instructive and the result is pretty satisfying so far. Along the way I learned a few things that might be of use for others wanting to do this kind of client. * The WebSocket API is a little short for this use-case: - we need an API for being informed when the connection is opened/closed. - it lacks an API for sending ordered messages. It could be Task-based, allowing to interrupt it one of the send fails, or it could be a "sendAll" Cmd that takes a list of messages to send. Both this issues were fortunately worked-around in my case, but it is only because the protocol allowed it. Others may not be so lucky. * Using an effect module is not mandatory... * ... but I had to mimick Cmd and Sub, which adds a lot of boilerplate for the user (see the project README) * not being an effect module has clear pros : - we can rely on other effect modules (in my case: WebSocket and Random) - Implementation is somehow easier, and more friendly to maintain - The module can be published on package.elm-lang.org * Being an effect module would allow a much simpler and natural API. But then we could not use WebSocket or Random Finally, I would like to discuss a notion of middleware (which I think is what I did with elm-nats): We could simplify the API as much as with an effect module if we could manipulate the Cmd and Sub. I suspect that being able to filter a Cmd to extract all Cmd of a given type in it would permit to implement some kind of middleware component. Such a component would be explicitely inserted by the user between its program and its TEA entry points. It could define some custom Cmd and Sub, and would transform them to other effect modules commands and subs just before returning them to the program. Has anything like this been attempted already? Am I making any sense? Best regards, Christophe [1] https://nats.io [2] https://github.com/orus-io/elm-nats -- 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 a protocol on top of WebSocket: should I build a effect module ?
This night I found a way to avoid pushing the nats State to all the components: now I just have them return NatsCmd along with their model and normal commands, which is what you describe in the first part of your email (I am still working on it). It makes the API a lot nicer, although the root component still has to apply those NatsCmd to the nats State (which is not too bad compared to before. As for the effect-module approach, I think I will insist on using a non-effect module until I hit some blocking issues solvable only with a effect module, like how to both dispatch a custom message and update my nats State in a single update, which would be needed when a subscription needs to be removed (after a auto-unsub). I will definitely have a look to elmq, thanks for pointing it out! Le 18/05/2017 à 10:46, 'Rupert Smith' via Elm Discuss a écrit : > On Wednesday, May 17, 2017 at 5:02:55 PM UTC+1, Christophe de Vienne wrote: > > The main thing that bothers me is that I will need to pass the > Nats.State to every update function because subscribing requires an > update of the state... And I see no way to avoid that except using an > effect module. > > > So you would rather that your Nats module kept its own state 'private' > and lets users of it send it a message asking to subscribe? > > Suppose your code has 3 update functions and is structured like this: > > Main (top-level update) > - Nats (updates Nats State as websocket conversation progresses) > - MyFunkyApp (does something cool. Needs to subscribe to Nats) > > The TEA pattern that you could use to do this, whilst keeping the Nats > state private, is to use an 'out message' from MyFunkyApp. Then have > some routing in Main, that passes the subscriptions requests to Nats, > where Nats can update its State in private. > > It can be a lot of boilerplate if you have lots of modules using Nats, > so I can see why the effects module approach is appealing. > > === > > I was eating breakfast this morning when it occurred to me that I may > have a solution for you; it is an effects module: > > https://github.com/rupertlssmith/elmq > > If we divide your Nats implementation into two independant (orthogonal) > parts - there is the websockets part, and there is a part relating to > how you plumb this re-usable protocol module into an Elm application. > The 'elmq' effects module could solve the second part for you. This > would mean that you don't need to write your own effects module for this > specific problem as the concept has already been captured by the elmq > effects module. > > === > > Here is an example of using elmq. Authentication is a very common > component of applications and I also felt that it was likely that many > modules in my applications would need to interact with authentication. > In particular, I have quite a few Json web services over HTTP - at any > time one of them may get back a 403 or a 401 and will then need to > update the auth state to say that we are not currently authenticated. > > To avoid all the 'out message' plumbing that would require, I built my > auth module on top of elmq. > > It provides an API, that stuffs event messages onto elmq channels: > > https://github.com/rupertlssmith/elm-auth/blob/master/src/Auth.elm > > And the AuthController is then able to subscribe to these messages, and > privately update its state: > > https://github.com/rupertlssmith/elm-auth/blob/master/src/AuthController.elm#L228 > > So you can see, it is very easy for a module to import the Auth API and > use it, without having to worry about the plumbing needed to update the > authentication state. > > === > > The elmq module was lifted from original code here: > https://github.com/gdotdesign/elm-ui > > One limitation of it is that you can only pass the primitive types or a > Json.Encode.Value. Anything else you must provide an Encoder/Decoder for. > > See the readme for elmq for some discussion points around how its API > could be evolved. I would be very interested to hear if you think your > use case fits it, or if you think it needs adapted a little to cater for > your need? Would also be very happy to take suggestions on board and > improve it. > > It is not an official effects module, so you must install it with > elm-github-install. > > If it is useful to you, it might be time to consider making a proposal > on elm-dev to push it towards becoming an official effects module. I > have considered this before, but was not sure if it would be well > received or not - its certainly quite a different way of doing things to > the TEA approach. Also as Elm is single threaded, and this is really an > asynchronous messaging model (like JMS for Java),
Re: [elm-discuss] Re: Implementing a protocol on top of WebSocket: should I build a effect module ?
Le 17/05/2017 à 09:15, Christophe de Vienne a écrit : > > > Le 17/05/2017 à 08:24, Wojciech Piekutowski a écrit : >> There's also https://github.com/fbonetti/elm-phoenix-socket/. It doesn't >> use an effect manager, but apparently because of that doesn't notify >> about disconnection. >> > > Very interesting. One limit I see is that only one type of Msg can be > emitted by the subscription, which forces to handle all the > subscriptions in the same component. > > In my case, I need the subscriptions to be initialized and used in > various components. I think I found a way to do that, I will put it on > github soon. > > Another limit I an hitting with a non-effect module, and for which I see > no solution, is when several messages arrive in a single websocket > message. In this case we should emit several custom message for one > incoming websocket message. > > Fortunalely, I can temper with the server and make sure one nats message > comes in as a single websocket message, which workaround the issue. > So, I have a first version of a Nats module, which handles properly the subscriptions (at least as I wanted it to). https://github.com/orus-io/elm-nats It is requires a nats/websocket gateway I wrote too (https://github.com/orus-io/nats-websocket-gw) The main thing that bothers me is that I will need to pass the Nats.State to every update function because subscribing requires an update of the state... And I see no way to avoid that except using an effect module. There are plenty improvements to do (starting with the documentation), but some feedback would be really appreciated. Thanks for all the helpfull response to my OP ! -- 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 a protocol on top of WebSocket: should I build a effect module ?
A nice place to start with if I want to go down the effect-module road. Although as Mark said it rely on the WebSocket.LowLevel module, which imply extra complexity in the implementation. The resulting API looks a lot clearer and more natural than the other phoenix implementation, which is a big bonus. Le 17/05/2017 à 01:38, Oliver Searle-Barnes a écrit : > You might find https://github.com/saschatimme/elm-phoenix useful to look > at, it's an effects manager phoenix channels built on top of the > websocket effects manager. > > On Tuesday, 16 May 2017 15:30:18 UTC+1, Christophe de Vienne wrote: > > Hi everyone, > > I am attempting to implement the pub/sub NATS (https://nats.io) > protocol > on top of the WebSocket API as a TEA component. > > I have a hard time finding an API for subscriptions: for each > subscription some context must be kept, a unique subscription ID > generated and in some case a unique reply subject too, and I would like > each subscription to generate custom messages for the component which > made it. > > I suspect it would be a lot more natural with an effect module, with > which I could (hopefully) write, in any part of the application: > > subscriptions : Model -> Sub Msg > subscriptions model = > Nats.Subscribe model.endpoint "some.subject" MyMessage > > or, for req/rep (a pub + a short-living sub expecting a result): > > myrequest : Model -> Cmd Msg > myrequest model = > Nats.request model.endpoint "a.request.subject" MyReply > > > Another difficulty I have is that in some cases I need to send 2 or 3 > messages through the websocket, in the right order, but WebSocket.send > returns a Cmd. So I have to concat the 3 commands in 1 message, which > works but oblige > > Am I wrong being tempted by using an effect module for this kind of > module ? > If so how can I mimick such an API with a TEA approach ? > If not is there any documentation I can read to get familiar with > them ? > > Is there any existing module that does this kind of thing for another > protocol ? > > Thanks! > > -- > 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 > <mailto:elm-discuss+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout. -- 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 a protocol on top of WebSocket: should I build a effect module ?
Le 17/05/2017 à 08:24, Wojciech Piekutowski a écrit : > There's also https://github.com/fbonetti/elm-phoenix-socket/. It doesn't > use an effect manager, but apparently because of that doesn't notify > about disconnection. > Very interesting. One limit I see is that only one type of Msg can be emitted by the subscription, which forces to handle all the subscriptions in the same component. In my case, I need the subscriptions to be initialized and used in various components. I think I found a way to do that, I will put it on github soon. Another limit I an hitting with a non-effect module, and for which I see no solution, is when several messages arrive in a single websocket message. In this case we should emit several custom message for one incoming websocket message. Fortunalely, I can temper with the server and make sure one nats message comes in as a single websocket message, which workaround the issue. -- 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] Implementing a protocol on top of WebSocket: should I build a effect module ?
Hi Mark, What you describe as an alternative to an effect module is more or less what I am building right now (well, I am attempting to anyway), which is encouraging :-) thanks for the feedback ! The question of effect modules using other effect modules also came up when reading some effect module source code. It would be nice having a definitive answer to it. Christophe Le 16/05/2017 à 17:56, Mark Hamburg a écrit : > I've been looking at similar issues for protocol handling. > > As I understand it — and I would welcome someone pointing to evidence > otherwise — effects modules can't use other effects modules. That means that > if you want to use web sockets, you either don't use some of the services > that effects modules provide (subscriptions, easy routing for commands) or > you build your own effects module possibly cutting and using the low level > web sockets module used by the web sockets effects module. (What's the > thinking on whether that's a recommended choice? My inference from the name > "low level" is "please stay away", but maybe that inference is mistaken.) > > If you don't want to go the low-level route, then you need to build something > on top of the existing web sockets effects module. > > For command-like behavior, this is relatively straightforward. For example, > you can change the return value from update functions from ( Model, Cmd Msg ) > to ( Model, Operation Msg ) where Operation is a type that mirrors and > subsumed Cmd while also allowing your top level code to route requests to > your protocol handling module and to route responses back to the rest of your > code. In some sense, this is what effects managers are doing. They just do it > with linguistic and runtime support so that you don't have to wire things up. > > Subscriptions can be handled in the same way. You can replace the > subscriptions function call with a call to something like `observations` and > get back a similar structure that subsumes regular subscriptions while also > allowing your top-level code to route items meant for your "user-mode effects > manager" to that manager. At this point, however, you will need to figure out > how often to call `observations`. My understanding is that Elm calls this > after every update but I don't think the documentation says. > > In other words, if you want to build an effects manager like piece of code > but don't want to write it as an effects manager — because, for example, you > want to use other effects managers — you can do so. You just need to build > parallels to the standard Elm infrastructure. > > You also need to reconcile yourself if this is concern to the fact that your > user mode effects manager will be storing functions in the model to remember > how to route responses. If it's any solace, that's what regular effects > managers do as well, so I wouldn't feel too bad about it. > > But maybe someone can render this whole message moot by saying "just write an > effects manager because there is no prohibition on one effects manager using > another". Of course, that would also be easier with documentation about how > to write an effects manager, but that's a different subject. > > Mark > >> On May 16, 2017, at 8:32 AM, Christophe de Vienne >> <christo...@cdevienne.info> wrote: >> >> >> >>> Le 16/05/2017 à 17:17, Christophe de Vienne a écrit : >>> Thank you for the feedback. >>> >>> I am still trying to find a non-effect based API. Did not find anything >>> satisfying so far. >>> >>> The WebSocket.LowLevel module is interesting for send batches, but my >>> main issue is how to associate a custom message translator to each >>> subscription in a global protocol state. >> >> Plus the WebSocket module provides very useful behavior I would prefer >> not to reimplement. >> >>> >>>> Le 16/05/2017 à 17:02, Aaron VonderHaar a écrit : >>>> Hi, I haven't played much with WebSockets, but I have been building a >>>> protocol on top of HTTP. I haven't yet run into an issue that made me >>>> think to try an effects module. >>>> >>>> Instead of having custom subscriptions, my package has an `update` >>>> function that takes any msgs resulting from its commands and returns >>>> some appropriate stuff (in my case, that is an optional output value >>>> that the caller can do something with, and also another Cmd to run). >>>> >>>> For the Cmds, I do have to use the Tasks portion of the HTTP API so that >>>> I can compose and chain things together (though I do in the en
Re: [elm-discuss] Implementing a protocol on top of WebSocket: should I build a effect module ?
Le 16/05/2017 à 17:17, Christophe de Vienne a écrit : > Thank you for the feedback. > > I am still trying to find a non-effect based API. Did not find anything > satisfying so far. > > The WebSocket.LowLevel module is interesting for send batches, but my > main issue is how to associate a custom message translator to each > subscription in a global protocol state. Plus the WebSocket module provides very useful behavior I would prefer not to reimplement. > > Le 16/05/2017 à 17:02, Aaron VonderHaar a écrit : >> Hi, I haven't played much with WebSockets, but I have been building a >> protocol on top of HTTP. I haven't yet run into an issue that made me >> think to try an effects module. >> >> Instead of having custom subscriptions, my package has an `update` >> function that takes any msgs resulting from its commands and returns >> some appropriate stuff (in my case, that is an optional output value >> that the caller can do something with, and also another Cmd to run). >> >> For the Cmds, I do have to use the Tasks portion of the HTTP API so that >> I can compose and chain things together (though I do in the end return a >> Cmd for most functions in my protocol's API). For WebSockets, I see >> there's >> http://package.elm-lang.org/packages/elm-lang/websocket/1.0.2/WebSocket-LowLevel >> which provides Tasks instead of Cmds, so it's likely you could use that >> for what you need. >> >> I don't know if those things will address all the needs of your >> WebSockets protocol, but those approaches have worked for what I've been >> building. (Sorry, it's not open-source, so can't share the code.) >> >> --Aaron V. >> >> On Tue, May 16, 2017 at 7:30 AM, Christophe de Vienne >> <christo...@cdevienne.info <mailto:christo...@cdevienne.info>> wrote: >> >> Hi everyone, >> >> I am attempting to implement the pub/sub NATS (https://nats.io) protocol >> on top of the WebSocket API as a TEA component. >> >> I have a hard time finding an API for subscriptions: for each >> subscription some context must be kept, a unique subscription ID >> generated and in some case a unique reply subject too, and I would like >> each subscription to generate custom messages for the component which >> made it. >> >> I suspect it would be a lot more natural with an effect module, with >> which I could (hopefully) write, in any part of the application: >> >> subscriptions : Model -> Sub Msg >> subscriptions model = >> Nats.Subscribe model.endpoint "some.subject" MyMessage >> >> or, for req/rep (a pub + a short-living sub expecting a result): >> >> myrequest : Model -> Cmd Msg >> myrequest model = >> Nats.request model.endpoint "a.request.subject" MyReply >> >> >> Another difficulty I have is that in some cases I need to send 2 or 3 >> messages through the websocket, in the right order, but WebSocket.send >> returns a Cmd. So I have to concat the 3 commands in 1 message, which >> works but oblige >> >> Am I wrong being tempted by using an effect module for this kind of >> module ? >> If so how can I mimick such an API with a TEA approach ? >> If not is there any documentation I can read to get familiar with them ? >> >> Is there any existing module that does this kind of thing for another >> protocol ? >> >> Thanks! >> >> -- >> 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 >> <mailto:elm-discuss%2bunsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> -- >> 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 >> <mailto:elm-discuss+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout. > -- 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] Implementing a protocol on top of WebSocket: should I build a effect module ?
Thank you for the feedback. I am still trying to find a non-effect based API. Did not find anything satisfying so far. The WebSocket.LowLevel module is interesting for send batches, but my main issue is how to associate a custom message translator to each subscription in a global protocol state. Le 16/05/2017 à 17:02, Aaron VonderHaar a écrit : > Hi, I haven't played much with WebSockets, but I have been building a > protocol on top of HTTP. I haven't yet run into an issue that made me > think to try an effects module. > > Instead of having custom subscriptions, my package has an `update` > function that takes any msgs resulting from its commands and returns > some appropriate stuff (in my case, that is an optional output value > that the caller can do something with, and also another Cmd to run). > > For the Cmds, I do have to use the Tasks portion of the HTTP API so that > I can compose and chain things together (though I do in the end return a > Cmd for most functions in my protocol's API). For WebSockets, I see > there's > http://package.elm-lang.org/packages/elm-lang/websocket/1.0.2/WebSocket-LowLevel > which provides Tasks instead of Cmds, so it's likely you could use that > for what you need. > > I don't know if those things will address all the needs of your > WebSockets protocol, but those approaches have worked for what I've been > building. (Sorry, it's not open-source, so can't share the code.) > > --Aaron V. > > On Tue, May 16, 2017 at 7:30 AM, Christophe de Vienne > <christo...@cdevienne.info <mailto:christo...@cdevienne.info>> wrote: > > Hi everyone, > > I am attempting to implement the pub/sub NATS (https://nats.io) protocol > on top of the WebSocket API as a TEA component. > > I have a hard time finding an API for subscriptions: for each > subscription some context must be kept, a unique subscription ID > generated and in some case a unique reply subject too, and I would like > each subscription to generate custom messages for the component which > made it. > > I suspect it would be a lot more natural with an effect module, with > which I could (hopefully) write, in any part of the application: > > subscriptions : Model -> Sub Msg > subscriptions model = > Nats.Subscribe model.endpoint "some.subject" MyMessage > > or, for req/rep (a pub + a short-living sub expecting a result): > > myrequest : Model -> Cmd Msg > myrequest model = > Nats.request model.endpoint "a.request.subject" MyReply > > > Another difficulty I have is that in some cases I need to send 2 or 3 > messages through the websocket, in the right order, but WebSocket.send > returns a Cmd. So I have to concat the 3 commands in 1 message, which > works but oblige > > Am I wrong being tempted by using an effect module for this kind of > module ? > If so how can I mimick such an API with a TEA approach ? > If not is there any documentation I can read to get familiar with them ? > > Is there any existing module that does this kind of thing for another > protocol ? > > Thanks! > > -- > 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 > <mailto:elm-discuss%2bunsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > 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 > <mailto:elm-discuss+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout. -- 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.
[elm-discuss] Implementing a protocol on top of WebSocket: should I build a effect module ?
Hi everyone, I am attempting to implement the pub/sub NATS (https://nats.io) protocol on top of the WebSocket API as a TEA component. I have a hard time finding an API for subscriptions: for each subscription some context must be kept, a unique subscription ID generated and in some case a unique reply subject too, and I would like each subscription to generate custom messages for the component which made it. I suspect it would be a lot more natural with an effect module, with which I could (hopefully) write, in any part of the application: subscriptions : Model -> Sub Msg subscriptions model = Nats.Subscribe model.endpoint "some.subject" MyMessage or, for req/rep (a pub + a short-living sub expecting a result): myrequest : Model -> Cmd Msg myrequest model = Nats.request model.endpoint "a.request.subject" MyReply Another difficulty I have is that in some cases I need to send 2 or 3 messages through the websocket, in the right order, but WebSocket.send returns a Cmd. So I have to concat the 3 commands in 1 message, which works but oblige Am I wrong being tempted by using an effect module for this kind of module ? If so how can I mimick such an API with a TEA approach ? If not is there any documentation I can read to get familiar with them ? Is there any existing module that does this kind of thing for another protocol ? Thanks! -- 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] Poll for Intermediate to Advanced topics that people struggle with
One thing I did not figure yet is how to make several components in a page efficiently interact with each other. Ideally I would like a single program with one model and several sub-views mounted on several nodes in the dom-tree (for example a basket widget and a "myaccount" one). I did such a thing with react/redux in a transition phase toward a SPA, and it was a nice way to iteratively integrate the new architecture in an existing application. The only way I can think of right with my current knowledge of elm is to use ports to have some messages sent from a component to the others, but it feels non optimal. I think having a clear way to achieve this would makes it easier to progressively integrate elm in an existing app. Le 24/04/2017 à 16:06, Jeff Schomay a écrit : > Hello, > > I am considering doing some training material on working with Elm in > production. I want to focus on areas that people struggle with after > they are already familiar with Elm. What concepts continue to confuse > you? What product requirements have been difficult to achieve with Elm? > What is most painful about your Elm codebase? > > Some topics I have already thought of: > > - decoders > - debouncing (http autocomplete input field for example) > - scroll to element > - testing > - unwieldy update functions > - api design > > If you have anything you'd like me to consider, please add it to the > list. Thank you! > > -- > 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 > <mailto:elm-discuss+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout. -- 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.
