Scope

WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

Unlike the global resolution mechanism at play in the world wide web, at the heart of ROC all resolution and request evaluation is performed relatively. This relativity is enabled through a data-structure called scope. Scope is a singly linked list of spaces. The space at the head of the list is called the nearest scope and this takes precedence over all others.

The Visualiser and Request Trace tools both give visual indication of scope. Use them to debug your applications or just to gain a deeper understanding of the concepts.

Within our discussion of ROC we shall see three distinct types of scope: request scope, evaluation scope and response scope.

Request Scope

Constructed requests must contain a scope field called the request scope. This scope determines which spaces are looked at and which order when NetKernel kernel resolves a request. By default this is transparently inherited from the evaluation scope of a parent request in all cases except for root requests issued from transports in which case it's scope is usually just the owning space of the transport.

Evaluation Scope

The evaluation scope is generated during the resolution process. This evaluation scope is placed into requests that are issued by the NetKernel kernel to endpoints. This scope then determines the default scope with which any subrequests will be issued with by that endpoint. It is possible for endpoints to override the request scope in sub-requests and this is the basis of many design patterns including pass-by-value and Overlay with dynamic space.

Response Scope

When an endpoint returns a response the kernel generates the response scope based upon a number of factors including the request scope, evaluation scope and the evaluation scope of any descendant sub-requests.

The response scopes intent is to determine the extent of request scope necessary to bound any computation and required resources. I.e. the minimum necessary scope that was necessary in evaluation the response. As such the response scope is always a subset of the request scope which always includes the nearest scope and then may contain zero or more other of its other spaces. The response scope is not a construct that a developer needs to use directly, however it is of critical importance to correct caching of responses because it distinctly identifies different resources even when they share common identifiers.