NetKernel News Volume 4 Issue 10

March 28th 2013

• Repository Updates
• Sets and Subset Identifiers
• Enlarging versus Reducing Set Identifiers

Repository Updates

Last time out, we shipped an update to the Golden Thread tools in layer1 to enable an accessor to list the currently assigned Golden Thread resources. This work was contributed by Tom Geudens, and with the release of this feature he discussed his use case and presented an Akamai-killing utility that exploits the power of the GT pattern.

During the review of this contribution an interesting discussion arose about explicit versus implicit constraint of an accessor's representation set.

Today I want to summarize our discussion and use it as a basis to articulate the trade-offs we are faced with when we choose the structure of resource identifiers defined by an endpoint's grammar.

Be warned there is no right and wrong answer, but there are levers you can select that, if you are aware of them, will result in better solutions.

Discussion

The new active:listGoldenThread endpoint has the following grammar...

The use of min and max quantifiers on the arguments indicate that these are optional constraints. You can read the docs for the details, but its pretty clear that the size of the listing representation can be controlled by specifying one or more of the arguments.

Diversion

If you're a seasoned reader of these newsletters then you'll be comfortable with the following question.

How should we interpret the identifier active:listGoldenThread when there are no arguments?

If you're getting started with ROC, or need a reminder, at this point it would be a good idea to read a couple of articles I wrote about two years ago.

1. What is a function?
2. Set theory: ROC and Web Functions

The first article discusses how we can conceptualize resource identifiers for infinitely large sets of resource representations even if they are either practically non-computable, or more fundamentally, unreifiable.

The second article discuss why thinking in terms of sets and subsets is actually the core principle behind the ROC abstraction (and as is shown, is the foundation and reason for the Web's success).

Resume

Returning to the question at hand: How to interpret and implement active:listGoldenThread?

The generalists answer might be: This is the potentially infinite set of all golden thread resources. Whereas a practical man might answer: This is a tool and it ought to behave well, so by default it will provide a "useful subset" and implicitly choose defaults for the arguments.

Tom is a practical man. He initially implemented the endpoint to default to limit the result to twenty golden threads if you supplied no arguments.

active:listGoldenThread

was equivalent to...

active:listGoldenThread+limit@20

This is a perfectly valid implementation, and given the domain of the resource model, its unlikely to lead to any shortcoming in the capability and, as I assume was Tom's intention, it ensures that the cost of this state to the system (CPU generation cost, caching cost etc etc) will mean that the tool "behaves nicely" by default.

However it begs a question. How, should I ask for all Golden Threads as a representation?

Perhaps you could ask for...

active:listGoldenThread+limit@none

Or maybe, you guess that internally the endpoint is constrained to the size of the largest Java integer...

active:listGoldenThread+limit@2147483647

The problem with the first approach is that it requires a special mode to handle the "none" argument making the code less elegant. The problem with the second is that it may be that your guess is wrong and that internally it is using long.

But, as I say, from an operational perspective, with this particular resource model, these two points are either not hard to deal with or pose no practical limitation on the value of the endpoint.

However, the high level objection to both of these approaches is rather more fundamental, since, ultimately they both require that the requestor has some explicit or implicit expectation and knowledge of the nature of the representation state of the resource model. This imposes an arbitrary and unnecessary coupling to any solution.

Without going into the reasoning I've used above, we agreed that the implementation that was shipped would not impose an internal default limit. The result is that if you request ...

active:listGoldenThread

... you will get all currently assigned Golden Threads and responsibility for balancing the engineering of any solution that uses this resources is left to the user, by them choosing appropriate constraints (limiting arguments).

Enlarging versus Reducing Set Identifiers

So now, with some background reading under our belts, and Tom's implementation example discussed, we get to the nub of the matter. Whenever we write a grammar for a set of resources we are faced with a fundamental and opposing design choice.

Enlarging: Do we construct the the grammar such that as we provide more arguments we enlarge the size of the representation set?

Or

Reducing: Do we construct the grammar so that its minimal resolvable identifier yields the largest possible representation set and any additional arguments have the affect of reducing (constraining) the representation set?

Putting it more formally, we see that the Enlarging style is one in which we start with a set and with arguments specify larger supersets. Whereas, by contrast, the Reducing style, starts with a large set (potentially uncomputably and/or practically infinite) and with arguments specifies subsets.

As I said in the preamble, there is no right or wrong answer. For example, one should always keep a toe in reality and bear in mind the innate limitation of the physical platform and if necessary fix internal engineering hard limits even with a reducing design.

However my gut, and my experience, suggests that if you can, its a looser, more powerful approach to ask for as large a set as you can with the least necessary qualification of the identifier.

Fortunately, I'm happy to point out, I am not alone and this was also the decision made by the designers of the SQL language over the relational database abstraction some 35-odd years ago. For example, contrast...

SELECT * FROM names;

with

SELECT * FROM names WHERE firstname='Tom';

surely, the canonical example of a reducing set identifier.