> What, fundamentally, is different between a box on the network to make CCNx work and a caching proxy?
Seems that you tell louder "what you want" and quieter (or not at all) "where you want it from".
Seems that PC doing CCNx would most of the time be clients *and* server.
So if a remote X connection needs a font to display some text, it would ask for the font file over CCNx, not ask the (maybe very distant) X server to provide the font file.
If a PC needs a file (package update, desktop background photo, ...) it asks over CCNx the file (giving its name, its version, some more info which identify uniquely what it wants - maybe the original reference server) and the nearest PC which has that file replies.
Posted Oct 25, 2012 12:40 UTC (Thu) by rswarbrick (subscriber, #47560)
[Link]
Ok, but if you want this to scale, you need some sort of unique ID for your document. There's the GUID approach, but that's not human-writable in the slightest. The other option is something heirarchical, where different content producers take bits of the total namespace. Of course, this is what people call a URL... (Or at least a URI)
I'm still massively not convinced that there's anything nontrivial here. I should probably go and have a careful look at ccnx.org and see if I can work out what they're doing. (and why)