~ubuntu-branches/debian/experimental/lazr.restfulclient/experimental

« back to all changes in this revision

Viewing changes to src/lazr/restfulclient/docs/caching.txt

  • Committer: Bazaar Package Importer
  • Author(s): Luca Falavigna
  • Date: 2010-04-29 21:42:36 UTC
  • mfrom: (1.2.1 upstream) (9.1.1 sid)
  • Revision ID: james.westby@ubuntu.com-20100429214236-vnuw5dmm2evm982u
Tags: 0.9.14-1
* New upstream release.
* debian/control:
  - Remove Conflicts/Replaces with python-lazr-restfulclient, they were
    useful for Ubuntu Lucid only.

Show diffs side-by-side

added added

removed removed

Lines of Context:
90
90
 
91
91
This will save you a *lot* of time in subsequent sessions, because
92
92
you'll be able to use cached versions of the initial (very expensive)
93
 
documents.
 
93
documents. A new client will not re-request the service root at all.
94
94
 
95
95
    >>> second_service = CookbookWebServiceClient(cache=unicode(tempdir))
96
 
    send: 'GET /1.0/ ...
97
 
    reply: ...304...
98
 
    ...
99
 
    send: 'GET /1.0/ ...
100
 
    reply: ...304...
101
 
    ...
 
96
 
 
97
You'll also be able to make conditional requests for many resources
 
98
and avoid transferring their full representations.
102
99
 
103
100
    >>> print second_service.recipes[4].instructions
104
101
    send: 'GET /1.0/recipes/4 ...
109
106
Of course, if you ever need to clear the cache directory, you'll have
110
107
to do it yourself.
111
108
 
 
109
Cleanup.
 
110
 
 
111
    >>> import shutil
 
112
    >>> shutil.rmtree(tempdir)
 
113
 
 
114
Cache expiration
 
115
----------------
 
116
 
 
117
The '1.0' version of the example web service, which we've been using up til
 
118
now, sets a long cache expiry time for the service root. That's why we
 
119
were able to create a second client that didn't request the service
 
120
root at all--just fetched the representations from its cache.
 
121
 
 
122
The 'devel' version of the example web service sets a cache expiry
 
123
time of two seconds. Let's see what that looks like on the client side.
 
124
 
 
125
    >>> tempdir = tempfile.mkdtemp()
 
126
    >>> first_service = CookbookWebServiceClient(
 
127
    ...     cache=tempdir, version='devel')
 
128
    send: 'GET /devel/ ...
 
129
    reply: ...200...
 
130
    ...
 
131
    send: 'GET /devel/ ...
 
132
    reply: ...200...
 
133
    ...
 
134
 
 
135
Now let's wait for three seconds to make sure the representations become
 
136
stale.
 
137
 
 
138
    >>> from time import sleep
 
139
    >>> sleep(3)
 
140
 
 
141
When the representations are stale, a new client makes *conditional*
 
142
requests for the representations. If the conditions fail (as they do
 
143
here), the cached representations are considered to have been
 
144
refreshed, just as if the server had sent them again.
 
145
 
 
146
    >>> second_service = CookbookWebServiceClient(
 
147
    ...     cache=tempdir, version='devel')
 
148
    send: 'GET /devel/ ...
 
149
    reply: ...304...
 
150
    ...
 
151
    send: 'GET /devel/ ...
 
152
    reply: ...304...
 
153
    ...
 
154
 
 
155
Let's quickly create another client before the representation grows
 
156
stale again.
 
157
 
 
158
    >>> second_service = CookbookWebServiceClient(
 
159
    ...     cache=tempdir, version='devel')
 
160
 
 
161
When the representations are not stale, a new client does not make any
 
162
HTTP requests at all--it fetches representations direct from the
 
163
cache.
 
164
 
 
165
Cleanup.
 
166
 
112
167
    >>> httplib2.debuglevel = 0
113
 
    >>> import shutil
114
168
    >>> shutil.rmtree(tempdir)
115
169
 
116
170
Cache filenames
152
206
caps filenames at about 240 characters so that cache files can be
153
207
stored on filesystems with 255-character filename length limits. For
154
208
compatibility with eCryptfs filesystems, lazr.restfulclient goes
155
 
further, and caps filenames at 150 characters.
 
209
further, and caps filenames at 143 characters.
156
210
 
157
211
To test out the limit, let's create a cookbook with an incredibly
158
212
long name.
181
235
    ...                              if 'amazingly' in file]
182
236
 
183
237
Indeed, the filename has been truncated to fit in the rough
184
 
150-character safety limit for eCryptfs filesystems.
 
238
143-character safety limit for eCryptfs filesystems.
185
239
 
186
240
    >>> len(cookbook_cache_filename)
187
 
    150
 
241
    143
188
242
 
189
243
Despite the truncation, some of the useful information from the
190
244
cookbook's name makes it into the filename, making it easy to find when
203
257
    ...     price=10.22, last_printing=date)
204
258
 
205
259
This cookbook's URL is identical to the first cookbook's URL for far
206
 
longer than 150 characters. But since the truncated filename
 
260
longer than 143 characters. But since the truncated filename
207
261
incorporates an MD5 sum based on the full URL, the two cookbooks are
208
262
cached in separate files.
209
263