Re: URL: Background and Requirements

Warner ten Kate wrote:

> I agree that the content stored on your local disc is at
> another location than the original one. How do we inform
> the application document using that content about the change ?
>
> I think we need both an URL scheme which points to a specific
> location, as some additional scheme which creates a level of
> indirection and enables to solve the type of problems I described.
>
> [Expanding the caching strategy, as described by Glenn Adams,
> to persistent storage (VCR) is interesting, and generates,
> a kind of implicit level of indirection: first look at your
> VCR than in the broadcast stream. There is, however, not a way
> to manage explicitly that 'indirection' scheme. For example,
> I am not sure how it expands if multiple storage media (camcorder)
> connected to an in-home network are involved. What are the (implicit)
> precedence rules ? Are all devices on the network to be checked
> if they contain the data requested (non-expired) ? Does it imply
> that during the original broadcast my user agent also has to check
> all my local storage devices at the in-home network ?]
>

Perhaps it helps to think of three different "families" of URLs.In particular:

1) broadcast URLs
   refer to assets obtained from broadcast streams,
   if such a URL is embedded in a broadcast stream
   and if the resource it refers to is in the
   same stream (ignoring for the moment whether this
   means elementary stream or transport stream) then
   the URL should still be resolvable if the stream is
   time-shifted (ie, recorded and played back)

2) home network URLs
   refer to assets stored on such things as CD/MD/DVD
   discs, AV servers, STB flash
   these assets may be copies of those in broadcast
   streams, purchased on storage media, downloaded
   from the Web, etc.

3) "normal" URLs - http:// and others currently in use


Simon

Received on Wednesday, 4 November 1998 17:00:00 UTC