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.
