Click slide for next, or goto previous, first, last slides or back to thumbnail layout.
A LIFN is constrained to name a particular series of octets. RCDS uses these internally (so that file servers can unambiguously refer to a particular version of a particular file), and as a binding between the resource description (catalog record) and the list of locations for a file.
RCDS clients can also use LIFNs as cache validators. If a catalog server says that the current version of a file has a particular LIFN, and a cache claims to have a copy of the file that goes with that LIFN, then the cached copy is known to be current.
Sooner or later someone usually asks whether LIFNs can describe things that aren't files, in particular, services. The current version of RCDS doesn't support this, but there's obviously a need for it. LIFNs, as currently defined, are both location- and time-independent, i.e. he binding between a LIFN and a file doesn't changer either according to the location of the resource or the time that the resource is accessed. This works well for ordinary files, because they don't change continuously and they change in discrete steps, but not so well for some kinds of services. (Imagine a very accurate, distributed, time-of-day service which returns the same time no matter which location it is accessed from, but does not return the same result at different times.)
It should be possible to define a variant of a LIFN which is location-independent but not necessarily time-independent. This would allow a service to be advertised at several different addresses, as long as the client can get the same results at any particular time from any of those servers. The next version of RCDS will attempt to support this.
Click slide for next, or goto previous, or back to thumbnail layout.