Swim lane diagrams
Apr. 19th, 2010 10:34 amThese really should have gone up a while ago, but given how I'm scrambling around to finish the school year (two more weeks!) I suppose it's not that big a surprise that it's been a long time coming.
Anyway, I've got some nice swim-lane diagrams for the project. Well, they're actually pretty ugly, but I do think they're illustrative. The first one is a somewhat simplified version of how comment requests currently work (as a general pattern of things), and the second one is how they would work if what I'm doing actually manages to take off...
The old way first:

And now the new way:

The big thing I'm trying to illustrate here is that what I'm working on adds some extra work, but it's purely synchronization work. The user never sees it, and if synchronization fails (for any reason) the system can fall back to local control. So if a sync call times out, or the sync service is down temporarily (or even forever), the system falls back to the old pattern seamlessly (if any of the blue arrowed steps fail, falling through to the next green arrow ensures continued functionality).
One thing of at least some concern to note here is that this specific implementation comes close to doubling bandwidth usage. The server the user connects to must both retrieve the conversation from and send it to remote systems in its entirety. It's pretty clear that this would be a lot better if it could send a request to the sync service asking only for updated comments/threads in order to cut down on that. Disqus, which I'm currently looking at, doesn't seem to do that, so it's not on the table now, but I'm pretty sure that long-term success depends on it being possible (and a number of other things, too, but one thing at a time).
Anyway, I've got some nice swim-lane diagrams for the project. Well, they're actually pretty ugly, but I do think they're illustrative. The first one is a somewhat simplified version of how comment requests currently work (as a general pattern of things), and the second one is how they would work if what I'm doing actually manages to take off...
The old way first:

And now the new way:

The big thing I'm trying to illustrate here is that what I'm working on adds some extra work, but it's purely synchronization work. The user never sees it, and if synchronization fails (for any reason) the system can fall back to local control. So if a sync call times out, or the sync service is down temporarily (or even forever), the system falls back to the old pattern seamlessly (if any of the blue arrowed steps fail, falling through to the next green arrow ensures continued functionality).
One thing of at least some concern to note here is that this specific implementation comes close to doubling bandwidth usage. The server the user connects to must both retrieve the conversation from and send it to remote systems in its entirety. It's pretty clear that this would be a lot better if it could send a request to the sync service asking only for updated comments/threads in order to cut down on that. Disqus, which I'm currently looking at, doesn't seem to do that, so it's not on the table now, but I'm pretty sure that long-term success depends on it being possible (and a number of other things, too, but one thing at a time).