… some rough brain dumps and follow-up observations…
- the assets on my side are static (so out-of-pocket hosting approximates bandwidth)
- each serving of the .fbx and .js consumes ~8.5k of data transfer (which includes headers)
- estimated hosting cost: one penny per 60,000 servings
Using hash fragments like
#v=1 seems preferable for static assets over querystrings like
querystrings tend to create virtual resources as a side-effect
- for a 10MB asset ?v=1 through ?v=5 travels the net as 5 resources x 10MB each
hash fragments are purely client-side state
- #v=1 through #v=5 still all refer to the same one resource
Hash fragments also offer a privacy improvement:
hash fragments are not sent to the server (so neither is your flickr configuration (to me))
- Apache logs the resource and IP address, but that merely suggests that someone (some IP) somewhere (??) did something (??)
- which user(s), domain(s), flickr settings or images remains a mystery
HTTP Cache Negotiation:
- Interface and Apache appear to be successfully negotiating!
- To upgrade assets I’d just upload new files. (changes then propagate organically, consistently)
- Hash fragments made testing cache behavior way easier and in part because the logs become more obvious (there are no virtual permutations to deal with)
- Interface uses different validation mechanisms for different resource types
- typically HEAD for models and GET/304s for scripts
- Currently a different loophole is used to trigger cache conversations manually:
- on the surface:
- under the hood:
- Interface perceives URLs w/different hash fragments as completely(?) different
- BUT the disk cache and networking ignore the hash (as they should)
- So varying the hash effectively just “reminds” Interface that it is time to phone Apache
- Which results in the negotiation: IF newer asset THEN download ELSE hang up.
Flickr serves the images themselves from a massively-parallel server farm (that already handles an incredible amount of simultaneous users and traffic). The bootstrapping assets are featherweight. The GPU and CPU overheads are basically nominal.
So… this thing is insanely scalable. Hundreds of users? Think bigger. (I am not suggesting abusing Flickr here; one day Flickr will form an opinion regarding such metaverse use cases; today it would take a substantial effort to become a blip on their radar at the resource level, or even to frame the discussion at all).
Side note: Web Entities are great (and could browse to Flickr directly), but they actually “cost” nearly as much as a browser tab – which is very, very expensive (in relative terms). A blank page already costs hundreds if not thousands of times more in general than eight vertices, four triangles and a bitmap. And this is per each instance of a Web Entity. There are solutions to that bottleneck but not yet convenient ones.
The photo plane would probably need to be taught a few more tricks (like best-fit autosizing to stay within bounds, specifying a starter image from a set, taking a flickr API key as a parameter, etc.). But then it would work almost like “metaverse duct tape.”
Because pretty much anything that is flat, rectangular and photographed becomes emulate-able:
- temporary traffic signage for your highway (#tags=highway+exit+signs ?)
- a picnic blanket (#tags=quilt+pattern ?)
- dynamic wallpaper – like for your walls (or ceilings (or carpets (or cabinets)))
- a placeholder crop of soybeans in the distance
- exterior graffiti