Re: XML? (no, caching)

At 09:09 AM 2000-10-07 +0100, jonathan chetwynd wrote:
>
>A question in view of the numerous concerns expressed regarding
>bandwidth taken up by graphics:
>
>Is it currently possible to link to the local hard-drive and use a local
>graphic if present, possibly with the option to download alternative
>graphics*?
>
>I am not certain about the following, but given that many sites
>including wai use a graphic repeatedly, is this already part of html? If
>so how does one simply ensure that the local graphic, if available was
>linked to?
>

There is functionality in the present infrastructure which does some of
this.  The browser typically keeps a cache containing recently-retrieved
resources.  Thus a logo that is used on every page on a site will be
retrieved once when one arrives at that site and then as one wanders around
at the same site the logo image will be recycled from the cache where it
was put when the first page was downloaded.  Technically, this is more the
browser's implementation of HTTP than HTML, but in the terms that you meant
the question; yes, it's in there, to this extent.

Caching policies, because they are buried under the sheets in the HTTP
implementation, are not always well understood, as is illustrated in this
recent thread on www-talk:

  http://lists.w3.org/Archives/Public/www-talk/2000MarApr/thread.html#9

If you wanted to go to the length of trying to avoid even the first
download by distributing a CD to your participating users, and have images
on the CD recovered from there when they were cited in a page, you would
have to venture into technology that is not so widely implemented in the
field today.  The URN technology is in part intended for this sort of use.
You would define your image collection as a catalog, with an indexing
scheme, and publish the indexing scheme in conformance with some registered
sub-scheme of URN.  Then on the CD you also have to distribute a catalog
server which when installed would let the browser know that it was prepared
to handle URNs of the flavor that you used.  You would also put a catalog
server and image collection up on the web, as well.  The scheme difference
(different from http:) would tell the browser to check with the nearest
available catalog server and if your users had installed the catalog
server, they would get local-first satisfaction of needs for images in the
collection.
For others thinking about this problem, check out the recent W3C Note:

Describing and retrieving photos using RDF and HTTP

http://www.w3.org/TR/photo-rdf/

I should not let this thread go without mentioning AKAMAI.  The trend in
actual use, at least in the U.S. where developments are coloured by money
from the server side, is not to require any special processing in the
client at all but to device schemes for distributed dispensing of the
content, so that it can be obtained from "a server near you."  The firm
AKAMAI has made a name for itself through excellence in this department.
The information provider with the necessary financial means puts their
information on a distributed service which places it on your side of any
bandwidth bottlenecks, such as the trip across the Atlantic.  This does not
require any system administration understanding from the end-users; and
that is a BIG WIN.


>---
>
>*A possible way to identify graphics uniquely* is to take a diagonal
>line through the field eg a 32x32 2 bit image might have the code
>10001010010011001110000110110100. Which could be in the header, or in
>the html.
>

A more Internet-standard way would be to compute the MD5 hash of the image
data.

rfc1321 - The MD5 Message-Digest Algorithm

http://www.faqs.org/rfcs/rfc1321.html

>*A colleague in another field devised a simple and fairly successful
>means for identifying 'GO' games.
>

Yes, these practices could be described as 'encoding methods' and there are
current best practices in the Internet community for some cases.  Your
colleague might be interested in joining the cypherpunks mailing list for a
real mind trip.

  The Cypherpunks Home Page
  http://www.csua.berkeley.edu/cypherpunks/Home.html

  The Mailing List
  http://www.csua.berkeley.edu/cypherpunks/mailing_list

...but not if they have any trouble reading or discarding email...

Al

PS:  Keywords for this question, in the orthodox web lexicon, would be
'caching,' 'URI' or 'addressing,' not 'XML,' per se.  

This demonstrates my standard line that "The people with the answers see
the world through a more fine-grained reticle (lexicon) than do the people
with the questions."  The standard situation is that you could have looked
it up if you knew what to call it.  But (catch 22) if you knew what to call
it you probably wouldn't have to look it up.  

On the other hand, there are outstanding problems with the handshake
between the existing consensus on best practice in addressing and XML in
the area of referencing schemas, for example.  See the inconclusive flame
war that took place on use of URIs in XML, archived at


http://lists.w3.org/Archives/Public/xml-uri/

So I don't want to give the impression that everything that needs to be
figured out has been figured out and written down, and you just need to
look it up.  There are reference resources that one should not ignore.  But
it's not all there, yet.

>-- 
>
>jonathan chetwynd
>jc@signbrowser.org.uk
>IT teacher (learning difficulties) 
>& accessibility consultant
>

Received on Saturday, 7 October 2000 12:28:41 UTC