Richard's definition of large application (36,000 lines) and my definition (Photoshop, Lightroom, ...) are rather different in scale, so maybe that's part of the difference in perspective and my sense that one needs to find good ways to carve things apart.
With that in mind, let me put an example out. Imagine working on something akin to Slack (or any number of other chat systems). For the view, we need an updating list of channels and for any channel, we need an updating list of messages. We need ways to create channels and post messages. This first really well with the 0.17 architecture. The lists of channels and messages are subscriptions. Channel creation and message posting are commands. Now, if these were working with a RESTful interface, we might generate the commands by generating HTTP tasks and converting those to commands and we would handle the subscriptions again by generating HTTP tasks coupled with timer tasks for when to re-query. But in the interests of performance and to avoid polling, the service is built using web sockets and speaks a particular message protocol to do so. Now, we really want to use the web sockets effects manager. But the commands and subscriptions it provides — particularly the subscriptions — don't really fit with the needs of the view. We want to maintain some form of local data model that interacts with the server via web sockets. That would be pretty easy but that data model then doesn't fit as neatly with the commands and subscriptions needed by the view. At least not when we essentially have to query it for "subscribed" values after every update — e.g., after every update to the data model, we need to fetch the list of forums and see whether it changed or the update function for the data model has to provide this information in a form that allows it to be routed to the subscriptions from the view model side. I want the UX developer and the client-side backend developer to get together and specify an API for what the UX needs and the abstraction provided by the backend. In this case, the commands and subscriptions listed above. I then want the UX developer to be able to go off and build using this API and I want the backend developer to similarly be able to go off and build the implementation of this API in as straightforward a way as possible. What it feels like we need is a way to build effects managers based on other effects managers and an embrace of effects managers as a more general part of the architecture rather than a piece used for a limited range of platform API interfacing to be written by a much smaller number of people. Commands and subscriptions are great ways to specify the communication between layers and to allow those layers to be built and maintained independently but they aren't really available for that purpose as far as I can tell from the 0.17 documentation. Or are there other patterns that allow the developers to agree on what needs to be done and get out of each others way as effectively as commands and subscriptions seem to do? Mark -- 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.
