Build 14: New code for injecting keystrokes

[Pocalypse]

But if all the Mojos know everything about all the WoWs that are configured to be launched, people will expect to be able to change the info on any copy of Mojo. But that won't work because the config info will break if the user makes a change while one Mojo is off and then later turns all the Mojos on and they find themselves out of sync with each other. So there has to be some limitation on info-trading, or some indication that one particular Mojo is in control, and I'm not sure how to do that without making the program seem complicated.

Do you cache the settings in a file somewhere (or in memory somewhere)? Then, when the already open Mojo with changes detects a new Mojo on the network, it can send over all the settings at the same time, and update the new Mojo.

I suppose then you have to start thinking about which Mojo has more up to date information, and the order in which Mojos are opened.

Just a thought.

[Freddie]

Do you cache the settings in a file somewhere (or in memory somewhere)?

Settings are saved in files.

Then, when the already open Mojo with changes detects a new Mojo on the network, it can send over all the settings at the same time, and update the new Mojo.

That works in that case but there are many other cases. Suppose one Mojo has run and been changed and shut down by itself. Then the same thing with the second. Then you start the first. Then you start the second. See the problem?

I suppose then you have to start thinking about which Mojo has more up to date information, and the order in which Mojos are opened.

Exactly. That's the problem. In general, it seems to be impossible to know which file is newer because the files have timestamps based on clocks in different computers.

I think probably the only way to do this is with a central repository for the info which means Mojo would no longer be 100% peer to peer. I'd like to hold on to peer to peer as a "100% design invariant" for the life of the project, if that's possible.

This problem has already arisen with mouseover and I handled it by creating entirely separate settings on each PC. I'm inclined to think the solution lies in that direction.

The basic idea would be, each computer is the master repository for settings that were created on that computer. As a result, each Mojo could have different settings.

It would be easier for me if each computer is the master repository for its own instances of WoW, but then maybe it starts to get complicated for the user.

[TheFallenOne]

Exactly. That's the problem. In general, it seems to be impossible to know which file is newer because the files have timestamps based on clocks in different computers.

I think probably the only way to do this is with a central repository for the info which means Mojo would no longer be 100% peer to peer. I'd like to hold on to peer to peer as a "100% design invariant" for the life of the project, if that's possible.

This problem has already arisen with mouseover and I handled it by creating entirely separate settings on each PC. I'm inclined to think the solution lies in that direction.

The basic idea would be, each computer is the master repository for settings that were created on that computer. As a result, each Mojo could have different settings.

It would be easier for me if each computer is the master repository for its own instances of WoW, but then maybe it starts to get complicated for the user.

Another option (food for thought):

Settings are saved with a version #, starting at 0, incremented by 1 every time the file is updated. The version number is also appended with a unique identifier specifying which computer the settings came from (maybe a MAC ID, some kind of product ID, or something similar).

When multiple computers connect, they compare version stamps. Say we have C1 and C2 connecting to each other. C1 has a settings file with version stamp as, say... 18-C1, and C2 has a settings file with version 16-C1. This indicates that C2 has previously received settings from C1, and automatically updates to 18-C1 from C1.

Now, if you update the settings on C2, they would be saved with the new version stamp 19-C2. This would be sent along with the last NON-C2 version stamp that the settings were updated from, and C1 would look at the incoming stamps, see that C2 has been updated from 18-C1 (which is C1's current version and the last non-C2 version stamp that was used) to 19-C2, and so it determines it should update too (since it's on 18-C1), and now saves it's version stamp as 19-C2.

Now for the part where things might get a little less straightforward... Both computers are on 26-C1, and you disconnect both computers. You do an update on both C1 and C2, and then reconnect them. Version stamps are compared, and since both have been updated independently, a "fork" is created in the settings tree. A dialog pops up, notifying the user that the settings from both of them do not match, and allowing them to choose whether to use the settings from C1, settings from C2, or leave them in a forked state.


I'm running on very little sleep, so I apologize if some of this is a little unintelligible. Anyways, just some food for thought, maybe you'll get some ideas from it.


EDIT: I also actually rather like the idea of "pushing" settings from one Mojo to the others (mentioned by Aragent above), ALA how Jamba handles things. I believe that would work rather nicely.

[Freddie]

Another option (food for thought):

Settings are saved with a version #, starting at 0, incremented by 1 every time the file is updated. The version number is also appended with a unique identifier specifying which computer the settings came from (maybe a MAC ID, some kind of product ID, or something similar).

When multiple computers connect, they compare version stamps. Say we have C1 and C2 connecting to each other. C1 has a settings file with version stamp as, say... 18-C1, and C2 has a settings file with version 16-C1. This indicates that C2 has previously received settings from C1, and automatically updates to 18-C1 from C1.

Now, if you update the settings on C2, they would be saved with the new version stamp 19-C2. This would be sent along with the last NON-C2 version stamp that the settings were updated from, and C1 would look at the incoming stamps, see that C2 has been updated from 18-C1 (which is C1's current version and the last non-C2 version stamp that was used) to 19-C2, and so it determines it should update too (since it's on 18-C1), and now saves it's version stamp as 19-C2.

Now for the part where things might get a little less straightforward... Both computers are on 26-C1, and you disconnect both computers. You do an update on both C1 and C2, and then reconnect them. Version stamps are compared, and since both have been updated independently, a "fork" is created in the settings tree. A dialog pops up, notifying the user that the settings from both of them do not match, and allowing them to choose whether to use the settings from C1, settings from C2, or leave them in a forked state.

Maybe I'm missing something, but it seems to me there are basically two main cases. In one case, the Mojos are running simultaneously and talking to each other. In that situation, whenever you change one Mojo, it tells the others. All changes immediately propagate. There's no need for version numbers or anything else.

The second case is what you call "less straightforward." It occurs when you change Mojo A while it's not talking to Mojo B, and then you change Mojo B while it's not talking to Mojo A. When they find themselves in communication again, they have no way to know which one was updated more recently.

If the first case doesn't require a solution, and your solution doesn't solve the second problem, what is it useful for?

Those two cases aren't logically exclusive so there must be other circumstances, but I'm having trouble getting a sense of how common they would be. Can you give me an example where version numbers would help?

EDIT: I also actually rather like the idea of "pushing" settings from one Mojo to the others (mentioned by Aragent above), ALA how Jamba handles things. I believe that would work rather nicely.

I'll look into Jamba. Thanks for suggesting it.