Resource Oriented Computing (ROC) uses a variation on dynamic scope to resolve requests. Dynamic resolution substitutes resolution of variables and functions with request resolution, and replaces statement blocks with spaces.
Each issued request has stack of spaces which we call the request scope. The resolution process involves attempting resolution in each of the spaces in turn until an endpoint is found. If no endpoint is found the request is deemed unresolvable.
One important point here is that resolution is always relative to the request scope. The implication of this is that resources are not absolute but relative to the observer, or should we say requestor.
Let’s look at how a request gets a request scope
To understand this we need a bit of background. In ROC any computation is always initiated by a root request. A root request is issued by what is called a transport. A transport acts as a client, constructing and issuing a request based upon some external stimulus. Examples include incoming network packets or events on a graphical user interface. Transports are initialized into a space. It is this single space which constitutes the request scope of the root request.
In resource oriented systems, endpoints issue subrequests to other endpoints just like functions call functions in functional languages or methods invoke methods in object oriented. Any non-trivial ROC system will involve deep subrequest trees. This happens when the response from one endpoint is computed using the responses from subrequests. (Just to be clear here, endpoints don’t directly issue subrequests to endpoints, I use that language here to be concise. Any sub-request is always resolved to an endpoint using the method described in this post as a whole).
Let’s look at how subrequests get a request scope
My previous discussion on modular addressing discusses how a tree of spaces is built with delegation. When the root request is resolved into a modular address space it may resolve down through imports and overlays. As it does it accumulates the spaces it resolves through, such that when resolution is complete the request scope has additional stack frames for each spaces the resolution has passed through. Subrequests issued by the resolved endpoint gain this extended scope.
A subrequest is issued with the scope gained from the resolution of the parent request. Each space in the request scope, which may contain delegating endpoints, is resolved in, in turn, until a resolution is found. If a space fails to resolve it is popped and the request scope shrinks.
It is worth considering why ROC doesn’t use the simpler static scoping that is more common in modern programming languages. Because ROC isn’t constrained within the syntax of one programming language but, rather, is distributed across heterogeneous space and endpoint implementations there is no sense of absolute lexical scope. It is the middleware of ROC that supports resolution rather than any particular language. It turns out that this rather unique characteristic is one that provides a unique benefit. Systems can be developed that span multiple programming languages enabling them to take advantage of the best tool for the job with a fine degree of control.