Changes between Version 5 and Version 6 of SharedTileCache


Ignore:
Timestamp:
2014-03-23T19:55:33+01:00 (12 years ago)
Author:
wavexx
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • SharedTileCache

    v5 v6  
    102102When an existing tile is being deleted, in addition to removing the associated "ini" file, the application must also try to remove the "/zoom/x/" and "/zoom/" directories when empty.
    103103
    104 When the cache size is defined as 0, applications '''must not''' perform any cache pruning. If size is anything greater than 0, each application can choose ''his own'' policy for tile expiration (which ''should'' usually be done by least-recently-used tile which is not currently visible), deleting each tile in turn until the size of the ''entire directory tree'' is smaller or equal to the defined cache size.
     104When the cache size is defined as 0, applications '''must not''' perform any cache pruning. If size is anything greater than 0, each application can choose ''his own'' policy and schedule for tile expiration, deleting each tile in turn until the size of the ''entire directory tree'' is smaller or equal to the defined cache size.
     105
     106=== Known tile metadata keys ===
     107
     108 etag:: ETag header as returned by the server (used by JOSM for tile caching).
    105109
    106110== Concurrent access ==
    … …  
    108112To enable "opportunistic" concurrent cache access to each tile cache, we define the following simple rules:
    109113
    110 * After deciding to create or update a tile, the image file ("/zoom/x/y.extension") '''must''' be moved ''atomically'' into the directory tree (and not created in-place), ''replacing'' any existing file (if any). At attempt can then be made to read the associated "ini" file. The "ini" file '''must be ignored''' if it's create/modification time is earlier than the image file and '''must''' then be deleted if not replaced.
     114* After deciding to create or update a tile, the image file ("/zoom/x/y.extension") '''must''' be moved ''atomically'' into the directory tree (and not created in-place), ''replacing'' any existing file (if any). An attempt can then be made to read the associated "ini" file. The "ini" file '''must be ignored''' if it's create/modification time is earlier than the image file and '''must''' then be deleted if not replaced.
    111115
    112116* When deleting an existing tile, the image file must be removed first, followed by an attempt to remove the "ini" file, and the x/zoom directories in turn.
    … …  
    115119
    116120* Updates to the cache properties and tile metadata '''must''' be similarly performed using atomic replacement. Since no locking is performed, applications almost '''must not''' cache their contents.
     121
     122With this approach, a tile being updated concurrently may remove existing metadata, however doesn't require any locking or sophisticated metadata syncronization. Moreover, it doesn't break the assumption that metadata is optional while guaranteeing that any data (when present) is not stale.