This should keep track of who is connected and detects reliably (I hope) when they disconnect. For now there's no user-to-user interaction in this test program, but I have already implemented it internally and will test it after we've first tested the reliability of detecting logins and logouts. Please run the program in as many accounts as you can - press Stop, kill the window, leave it running - whatever. Let me know if you see any major glitches.
"Our problem is that we never do the same thing again. We get a lot of experience on our first simple system, and then when it comes to doing the same thing again with a better designed hardware, with all the tools we know we need, we try and produce something which is ten times more complicated and fall into exactly the same trap. We do not stabilise on something nice and simple and say `let’s do it again, but do it very well this time.'" - David Howarth, 1972 Using @TheLogFather's cloud encoder. Full protocol details will be posted in the AT forums eventually ( https://scratch.mit.edu/discuss/topic/193387/ ) Have you read "Lord of the flies"? Everyone sits in a circle and passes a conch shell around from person to person. Only the person holding the conch shell may talk. They can talk to anyone in the circle and that person may answer, but the person with the conch controls the conversation. This project implements that protocol and builds on it to form a reliable inter-process communication mechanism, eg to support multiple instances of two-player games for example. TO DO: 2) remove cloud recipient and outgoing message if active user died while sending 3) timeout if recipient doesn't respond within timeout 5) if you detect you are not in 'users', add yourself (at any time, not just at startup) 6) if active user is not in users, take the active user slot. be careful about simultaneous grabs. (partially done) 7) when sending IPCs, if the target user is not in Users, skip that queue item until later. 8) detect 'appnap' sleep. wake when response improves. second 'sleeping' list for slow users? Should you put yourself into appnap or do we have someone do that to you? 9) put *all* cloud variables concerning cambridge ring into one cloud list - fixed fields first then the users array. Leave the other cloudvars free for the apps. 10) suppress display of userlist on first user joining until dead wood has been cleared.
