| François-René Rideau ( @ 2003-11-16 07:10:00 |
| Entry tags: | distributed software, en, smop, snail, tunes, versioning |
Decentralized versioning?
Once again, my main server Samaris is currently down. (I dunno why yet, I'll have to go to Paris to assess the nature of the failure, software or hardware; it lost two harddisks in last 24 months; I hope that's not a third hit.) Even when it's up, I don't have an internet connection at my current home, and I like to write on a variety of devices with network topology and reliability such that I can never rely on there being a central server easily within reach of every place I work at. Yet I want my computers to share data, spread backups, manage evolving versions of what I write, etc.
Hence, I often work in setups where some computers are not directly connected to other computers, but are updated through data copied on a harddisk or some other persistent media, that is moved around or otherwise made available for sharing to many other puters after having been pumped off the big 'net. I like call that Very High Latency Very High Throughput Multicast Networking, make it VHLVHTMN; or maybe just SNAIL: Slow Networking with Atrocious Interchange Latency. My guess is that beyond uses by people like me, it could be key to many applications in the Space Age. (ok, this age isn't quite as soon as we'd wish, and we'll prolly be mostly stuck on Earth as long as Black Magic rules the world, but I can still imagine quite a few uses for SNAIL technology, especially to allow people to seamlessly exchange data in ways that governments can't control.) Problem is, I can't seem to find software able to take advantage of such setups.
All networking systems I know rely on bidirectional information exchange in real-time (well, with a timeout of 5 minutes for a TCP round trip), at least for the control channel, before to even begin transmitting. TCP/IP claims to put "Intelligence at the end of the network"; well, maybe, but then each host has its own intelligence and is completely conspicuously utterly dumb about what the other end wants and is unable of any anticipation whatsoever. At least that's the standard TCP/IP way of doing things. Another way of seeing this sorry state of the industry, is that current Internet applications try to fake perfect synchronization of data up to the latency of transmitting whichever required partial data; and they have a variable success at that. Now the mistake is that they should be managing decoherence instead of making this hopeless attempt at faking coherence. (See what Paul Dourish says about that in his PhD thesis.)
OK, so the need for is here and will only grow, technology is available, algorithms are well-known (even when they aren't it won't be difficult to get something infinitely better than the complete utter lack of support currently available): big "messages" consisting of persistent application data that encode atomic transactions that can be replayed many times even after having been superseded by newer data; a data model based on an essentially a monotonic epistemic logic. GUIDs for machines, messages, locations, content, etc., and OpenPGP-style encryption and signatures built into the routing metadata. Based on these principles, it looks like a SMOP. Why hasn't anyone started coding? Or has someone already done it? Presumably, there already exists tens of mockup programs in C or such other lame static language, and hence incapable of interoperating with anything that wasn't built with said infrastructure from the ground up. And that's the catch with non-reflective language: you can't add stuff beneath the code, only on top. Or you need massive global modifications all over the code.
Enough ranting. I guess the one to code that will be I, unless I can convince someone else to do that for me (same for other SMOPs I have to propose such as email stamps, zzz or TUNES; nah, TUNES ain't a SMOP yet, only parts of it are). Hey, Gustavo, your school is keen on modal logic, couldn't they be interested in such things? Epistemic logic is exactly the thing about such networking.