I propose two HTTP header extensions.
First, XMPPSubscribe would contain an XMPP address which can be used by the client to subscribe or unsubscribe from changes made to the URL. The spec for the actual communication between the client and the XMPP address has yet to be resolved, but it would basically pertain the user sending the address a subscribe URL or unsubscribe URL message, and the address sending the client DOM updates of some sort.
Second, DHTKey would contain the key representing the file or its manifest file. Provided this, the client would download the file in a semi-reverse manner, such that the combination of the original HTTP transfer and the accompanied DHT transfer make up the file in question.
What do these headers provide? The first one provides the ability to send non-polling based updates to the client’s copy, and the second one provides bandwidth savings for the host, as well as theoretically faster download speeds for the client.
Together, these would provide the host frameworks for the nuWeb Project
As I continue my quest at web domination, I stumble across this interesting page on Distributed Hash Tables. From what I understand, data is routed to different parts of the network based on its hash. So, data with hashes that start with 4 be stored and retrieved in one area of the network, while hashes that start with 7 will be in another.
My confusion comes to looking at the implementations. It looks like they permit any key to be used, not just a standard hash of the value. If that’s the case, then these implementations are not what we want. What we want is a DHT where the keys are the hashes and the values are the data that the hashes represent. Therefore, there will almost never be two values with the same key, and so forth.
My thinking now is that data larger than about 1 MB should be split up into 1 MB blocks, each block put into the DHT, a manifest made of the hashes/keys, and that be inserted. If the manifest is larger than 1 MB, then it too is split up as well, and so forth.
We then finally provide the two magical functions, put(data) and get(key). put(data) returns its key, and get(key) returns the data. Simple as that; imagine the possabilities!
If you’ve ever wanted to make a bootable backup volume, here’s how I did it.
- Make sure “Ignore ownership on this volume” is turned off for the volume you wish to backup to. Select the volume, choose Get Info from the File menu, expand the Ownership & Permissions pane if it is not already expanded, and uncheck that option.
- Run
sudo ditto -X --rsrc / /Volumes/Backup\ Volume/
- Run
sudo bless --folder /Volumes/Backup\ Volume/System/Library/CoreServices
Of course, for step 2 and 3, replace Backup\ Volume with the name of your backup volume.
