Agreed. However, caching should not be mandated/exposed in the VRML language,
but should be left up to the vrml viewer to implement as they wish.
> Another approach to caching would be to create long (32 or more bits) ID
Experience with the IBM AS/400 shows that 32 bits is insufficient and can
easily be depleted, especially if one is sloppy with how they are handed out.
Maybe a more-to-the-home example is X11 resources -- 32 bits, and very, very
quickly depleted.
64 bits, or (gasp) 128 bits would be a better idea. That way, you can
hand out entire ranges without worrying about reserving a scarce resource.
> numbers for each object (based on the creator of the object and the time of
> creation). When we download objects, if we have cached the object with that
> ID, we simply read in the object locally. When we clean out our local
> cache, we might keep a database of ID's and where we have seen those objects
> before, along with some indication of how good the connection was when we
> downloaded that ID (bytes/sec download time). We could then choose to read
> that object from the machine that has the best connection (and then update
> the "quality of connection" data for that computer).
>
> For instance, if I "borrow" (with permission, of course) a refrigerator
> (ID number 2948375674837) from an international site with a slow connection
> for a scene that I have built and someone visits my scene before visiting
> the international site where the object originated, they can either re-use
> the refrigerator they got from me, or download it from me again if their
> connection to my machine is better than the connection to the international
> machine.
>
> Advantages:
> - always getting the correct object (not just something similar to that
> object).
> - good speed-up in communication without huge cache space requirements.
> - could set up a cache on a local machine that contains the cache for all
> of the machines at your location and you would never have to keep a cache
> on the machine that you use (as long as you update the ID database on
> all of the local machines correctly).
> - You see what the designer of the scene wants you to see.
> - no class definitions required.
There is another interesting use --
one could query a URL for it's "ID". If it's ID matches what you have
in hand, you know that your cache is valid. If the URL's ID has changed,
you know that your cache is invalid (stale).
> John B.
> -------------------------------------------------------------
> John Barrus
> Mitsubishi Electric Research Laboratories, Inc.
> 201 Broadway Phone (617) 621-7535
> Cambridge, MA 02139 FAX (617) 621-7550
>
Sincerely,
Linas Vepstas
^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^
Linas Vepstas Graphics Architecture
AWD IBM Austin VNET: AUSVM6(LINAS)
Zip 9260
Dept E84S, Bldg 902 Tie Line: 678-1116
11400 Burnet Road External Phone: 1-(512)-838-1116
http://w3.austin.ibm.com/afs/austin/u3/linas/public/html/home.html
local: linas@austin.ibm.com
internet: linas@innerdoor.austin.ibm.com
^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^