These are chat archives for jdubray/sam

28th
Jan 2017
Slađan Ristić
@sladiri
Jan 28 2017 17:30

The corresponding unit of work (model) looks like this:

{ 
            name: "newItems",
            order: 1,
            update: function(model,data) {
             // Accept search results
                if (data.items) {
                    model.data.home.portfolio.items = data.items ;
                    model.update.p = true ;
                }
            }

@jdubray Could you please explain in your example, who decides that the update unit of work is required specifically? Are all called always instead?

Jean-Jacques Dubray
@jdubray
Jan 28 2017 18:15
yes, they are all called, if the proposal does not contain items, then it returns. Union types might provide a smarter implementation. That's kind of "brute force" (aka naive).
Slađan Ristić
@sladiri
Jan 28 2017 18:22
Thanks @jdubray.
I think about the NAP order in relation to rendering: It should not matter, conceptually, a renderer receives the state as a message, like the NAP function does. In a general messaging system, you are not guaranteed which recipient will receive the state first, if they receive it at all. It reminds me of the Actor model.
Jean-Jacques Dubray
@jdubray
Jan 28 2017 18:26
however, there some aspects of the DOM that requires "next-action" to happen after the rendering. I do understand however that there are sometimes a need to complete the next action before you render, but that can be decided in the State function. But I respect the general criticism/skepticism about that part of the pattern. It's not "clean" because it's heavily influenced by rendering the view in the browser.
Slađan Ristić
@sladiri
Jan 28 2017 18:33

I guess I will run soon into situations, where that order is required. :)
Also I think that the notion of a physical "black box" machine, which responds with Responses to Stimuli is what SAM says. There is a restriction of such a machine: Its response at moment t cannot be depend on an input at moment t. That looks like the step that occurs when a model has processed an action and called the state function, doesn't it? I just read it in Computation Finite and Infinite Machines by Marvin Minsky, looks like a nice book.
This restriction is very physical, that no signal can pass at infinite speed, and it prevents paradoxical behaviour by the machine.

And in our application it was also easy to mock up a clean proof of concept with important aspects like client side and server side validation for a single page application.

Jean-Jacques Dubray
@jdubray
Jan 28 2017 18:36
Yes, this is true of physics too. When you study Quantum Electro-Dynamics (not that I want to pretend I know much about it), you cannot go below the resolution of an interaction
blob
Slađan Ristić
@sladiri
Jan 28 2017 18:53
:) Interesting.
I am assuming messaging here: By the way, I stumbled on this pattern while reading a bout UML state machine diagrams too. UML has stm diagrams (behaviour) and also a specialisation, the state machine protocol diagram. The protocol defines pre-conditions and post-conditions before a state transition is done. Looks like the model is the general state machine, but the interesting part is the protocol, which is the state function it seems. It defines what actions are allowed for example.
For a SAM system, the general STM diagram may contain just one state waiting for action, while the protocol is more complex and interesting to the user. If the user has to deal with the internals of the model, it is like having to know what a dumb form input wants for example, instead of being a good user experience which guides the user (with a protocol).
I thought about the car battery example, and often in real life the protocol is implicit. Physics "decides" whether you can start the car.
Joe Armstrong (Erlang) also recently warned that we "forget" about the most important part in messaging systems is the protocol.
This is very new to me so take what I say with a teaspoon of salt. :)
Jean-Jacques Dubray
@jdubray
Jan 28 2017 19:17
@sladiri what it is important to understand is that, that kind of "state machine" is observed. Yes, it is a protocol, it is not a programming model. That's a subtle difference, but a very important difference. You cannot mix protocol (inter-action) with programming model (what happens to the system when an action is applied).
The way to look at it is that every node in a distributed system is a SAM node. In particular next-actions can send proposals to other SAM nodes. There is nothing that says that the next-action is reflexive.
Slađan Ristić
@sladiri
Jan 28 2017 19:21
exactly, these two diagrams seem to show that distinction for example. Yes, I agree, that is why I chose to implement a prototype SAFE container like project with messaging. Sam nodes look like actors in the Actor model.
Jean-Jacques Dubray
@jdubray
Jan 28 2017 19:24
Yes and no, you can implement an actor with a SAM structure, can compose such actors in partent/child relationships, but in essence, SAM assumes a system state. Depending on the architecture you might have to manage the dehydration/rehydration of that state. In the browser you don't have to worry about that. On the server (and SAFE implements it) you have to deal with that issue head on.
Fred Daoud
@foxdonut
Jan 28 2017 20:15
@jdubray is SAM still SAM without nap()? Can the problems solved by nap() be solved in other ways? For example, the DOM manipulation that needs to be done after rendering, can be done with lifecycle hooks in VDOM libraries such as Mithril and others.
I ask because I am wondering whether removing nap() from Meiosis might simplify some things. Not the least of which the concern over async rendering vs nap().
Jean-Jacques Dubray
@jdubray
Jan 28 2017 20:17
sure, nothing wrong with that, but you might have next actions that are not DOM related. For instance in the fishing game sample, I "count the fishes" via an action triggered once the net has been deployed.
Fred Daoud
@foxdonut
Jan 28 2017 20:17
so how would you solve that if you didn't have nap()?
Jean-Jacques Dubray
@jdubray
Jan 28 2017 20:18
Clearly nap() interferes with rendering, but it should work, it's more problematic when you are running in client/server architecture where the model runs on the server.
I don't think it's wise to remove it. You can simply limit the scope of nap() with respect to rendering. In other words, you can find a better rendering architecture and then use nap only for system actions (not DOM actions).
Fred Daoud
@foxdonut
Jan 28 2017 20:21
that is sensible
thank you JJ
Rodrigo Carranza
@DrecDroid
Jan 28 2017 21:37
I was thinking, if naps are executed synchronously and so one nap is executed because of some state of the model and executes and action that leads to the execution of the same nap and enters in an infinite loop, this could cause other naps to never happen, and it's not so difficult to enter in this bucle.
Jean-Jacques Dubray
@jdubray
Jan 28 2017 21:40
Are you telling me that you cannot write infinite loops in regular code? only SAM would lead to infinite loop? A micro-container like SAFE can easily detect these conditions (model.changeSummary === null && state.nextAction !== null)
Rodrigo Carranza
@DrecDroid
Jan 28 2017 21:45
I'm just pointing out how this could happen in SAM
Jean-Jacques Dubray
@jdubray
Jan 28 2017 21:45
yes, absolutely.
Rodrigo Carranza
@DrecDroid
Jan 28 2017 21:48
I'm taking an approach where naps are attachable and considering that rendering is one other nap more. That could make easier to move to the server as we are only working with naps
Jean-Jacques Dubray
@jdubray
Jan 28 2017 22:11
Server-side rendering simply means preparing a response (state representation) and returning it as a request (for action). So the pattern works well there. I have also implemented the pattern with a dispatcher on the client and the action/model running on the server. The model is passed to the state function which runs in the browser (along with nap).
Jean-Jacques Dubray
@jdubray
Jan 28 2017 23:18
A SAM IoT sample is coming ...
blob
I am using TI CC2650 SensorTag and EvoThings Cordova SDK, streaming data to my cloud server.
Slađan Ristić
@sladiri
Jan 28 2017 23:22
Yes and no, you can implement an actor with a SAM structure, can compose such actors in partent/child relationships, but in essence, SAM assumes a system state.
I agree, SAM is no silver bullet for all systems. :)
Jean-Jacques Dubray
@jdubray
Jan 28 2017 23:23
what?? :-)
Slađan Ristić
@sladiri
Jan 28 2017 23:33
Oh, sorry about the formatting :)
I agree, SAM is no silver bullet for all systems, as in, it does not magically create some global system state in an actor system.
Jean-Jacques Dubray
@jdubray
Jan 28 2017 23:34
just joking about your comment... SAM is a not silver bullet??
Slađan Ristić
@sladiri
Jan 28 2017 23:41
:D sshh