diff options
| author | David Walter Seikel | 2016-02-20 12:31:37 +1000 |
|---|---|---|
| committer | David Walter Seikel | 2016-02-20 12:31:37 +1000 |
| commit | 080e27a38c508b2370cfe7f0152183f99a17131a (patch) | |
| tree | 7a153d59ce96915416e4788b73554e1e7739230d /docs/common/OMG-WTF-BBQ.html | |
| parent | Run the docs through a spell checker. (diff) | |
| download | SledjHamr-080e27a38c508b2370cfe7f0152183f99a17131a.zip SledjHamr-080e27a38c508b2370cfe7f0152183f99a17131a.tar.gz SledjHamr-080e27a38c508b2370cfe7f0152183f99a17131a.tar.bz2 SledjHamr-080e27a38c508b2370cfe7f0152183f99a17131a.tar.xz | |
Rearrange the docs.
Diffstat (limited to 'docs/common/OMG-WTF-BBQ.html')
| -rw-r--r-- | docs/common/OMG-WTF-BBQ.html | 25 |
1 files changed, 25 insertions, 0 deletions
diff --git a/docs/common/OMG-WTF-BBQ.html b/docs/common/OMG-WTF-BBQ.html new file mode 100644 index 0000000..5e48a14 --- /dev/null +++ b/docs/common/OMG-WTF-BBQ.html | |||
| @@ -0,0 +1,25 @@ | |||
| 1 | <html> | ||
| 2 | <title>OMG WTF BBQ</title> | ||
| 3 | <head> | ||
| 4 | </head> | ||
| 5 | <body bgcolor="black" text="white" alink="red" link="blue" vlink="purple"> | ||
| 6 | <p>The rationale</p> | ||
| 7 | <p>Scripts, and sometimes objects, can invoke a file purely by its UUID. It had been suggested we might replace the existing UUID system with something where the file is invoked via some sort of machine address, pointing to the Internet address of the grid or world -- actually, call it an OMG Node -- the file originated from. The problem with this sort of approach is that, a given VR world could go away, making that direct addressing fail, a given world could change its name and location, causing the direct addressing to break. What we need is a system where the UUID of a file is location-agnostic. That is to say, it shouldn't matter where the file originally came from, it should only matter that there is still a way to bring it in when you need it.</p> | ||
| 8 | <p>At that, while it might be possible to go into a script and change the machine-address for the file if it breaks, that makes the assumption one would be able to edit the script, or know what the new pseudo-UUID for that file would be in order to replace it. For one thing, a lot of scripts are going to be no-mod, so even if you did know what that new pseudo-UUID to replace in there was, you wouldn't be able to fix it anyway.</p> | ||
| 9 | <p>What needs to exist is some means of identifying what world a given set of files came from by some kind of UUID subset. That is, each file made on a particular, distinct part of the OMG needs a unique identifier that starts out all UUIDs made there, and that the rest of the UUID would be appended to that would uniquely identify a file that was created there. This unique identifier for an OMG Node also needs to exist in a form that doesn't change when the name or location of the OMG Node changes.</p> | ||
| 10 | <p>OMG Node</p> | ||
| 11 | <p>This would be a server or group of servers that function as a single entity. I.e. the gridrid and the sims that are specifically owned by a person. Another might be the server sim-providing service Waki and Torben are now setting up.</p> | ||
| 12 | <p>WTF -- Where's The File</p> | ||
| 13 | <p>This would be a list of UUID-identified files (pictures, sounds, notecards, scripts, etc) available from a given OMG Node that are currently known on your current machine, and would function as a sort of look up table if those UUIDs get invoked again. It identifies where a particular file came from originally, and/or what machines it traversed getting here. There would be one .WTF file for each OMG Node, and would list all the files that came from there which the local OMG Node has collected in its own interactions with other OMG Nodes, and that are reachable in a Six Degrees of Separation from Bacon sort of way. Basically, any UUID which starts with the code that identifies it as having come from that specific OMG Node would be stored here.</p> | ||
| 14 | <p>BBQ -- Big, Broad Query</p> | ||
| 15 | <p>Here is where the Six Degrees of Separation from Bacon mentioned under the WTF entry comes in. A .BBQ files keeps track of all the OMG Node identifier UUID-subset codes so that when an OMG Node changes its address or ceases to exist, every back address is stored, also, what other places maintain mirror copies of some or all of the files from there that could be called by a full UUID (from inside a script, say) so even when an OMG Node goes away, those files will continue to be available.</p> | ||
| 16 | <p>Basically, if a UUID is invoked by a script, and the file that UUID is tied to isn't in the local OMG Node, a query will be sent out to the nearby OMG Nodes asking if they have this file, if they don't, they might query their nearby OMG Nodes to see if those have it, and so on. Ideally there should develop from that, ant-tracks-style, that identifies the shortest path between OMG Nodes to where files with a given OMG Node identifier UUID-subset's files can be obtained from, even if that OMG Node has been out of business for a decade.</p> | ||
| 17 | <p>COW -- Copy On Write.</p> | ||
| 18 | <p>What's a BBQ without some COW, er I mean beef? We can speed up the BBQ search a bit by pre caching things, but what to pre cache and how?</p> | ||
| 19 | <p>Instead of using UUIDs, which are basically random numbers, we could use SHA1 hashes. This is the same system used by git at least. That means the objects can be content addressable. First benefit is that all these identical copies of any given object would end up with identical names, so that we have a broader field to search. Second benefit is that we don't end up having to store dozens of identical copies of the same object on the local OMG node, since they all end up with the same name. A UUID is 16 bytes, an SHA-1 is 20, but a UUID is usually shown in a format that includes 4 dashes, so they end up being the same length. Much experience with git has shown that you can get away with just the first few digits, depending on how many objects you need to distinguish between. So instead of completely ignoring the half a dozen copies of any given object you are searching for; coz different people uploaded it from different places; you might find it more easily by noticing that you already have it. The .WTF file can include pointers to known locations, and the various names it is known as, but the object itself has the SHA1 hash as it's file name, instead of the UUID. The SHA1 hash is it's internal name. It does not even have to be stored on the local OMG node, just the SHA1 internal name, and some pointers to likely locations.</p> | ||
| 20 | <p>Where does the COW come in? If it's got horns, any where it wants to. Er...</p> | ||
| 21 | <p>Quite often an object gets changed, that would naturally change the SHA1 hash. So now we have a different object, with a different name. But, the object might not be stored locally, just the pointer. The programming field has a name for what happens next, a copy is made when you try to write to it - Copy On Write. So the object is copied from the most convenient nearby OMG node, the changes made, then it is written (under a new SHA1 hash name) onto the local OMG node. This OMG node informs other interested nodes that it now has this new object, they can store pointers to the new object on this OMG node in their .WTF files.</p> | ||
| 22 | <p>Which brings us back to the pre caching. The hungry little OMG node does not have to wait for the BBQ to fire up to get it's COW. It can start to download the object if it has some time on it's hands, just coz.</p> | ||
| 23 | <p>To quote a famous local sporting hero "Where's the cheese?". Ah, that's another story...</p> | ||
| 24 | </body> | ||
| 25 | </html> | ||