I’m providing my own implementation of IActionInvoker, currently by extending ControllerActionInvoker, and as part of this work, I’ve done a quick audit of the methods of this class, and the order they are called in.

I’m reproducing them here, in case it’s useful to anyone else:

• InvokeAction
• GetControllerAction
• FindAction
• GetFilters
• InvokeAuthorizationFilters
• GetParameterValues
• InvokeActionMethodWithFilters
• InvokeActionMethod
• CreateActionResult
• InvokeActionResultWithFilters
• InvokeActionResult

The fourth movement is an old-fashioned rondo with lots of tunes; however, the original idea was rhythmical rather than melodic, and these rhythmic concerns recur throughout the movement.

Perhaps the decisive moment for me in writing this movement was when I noticed a rhythmic parallel between a Latin poem and an Italian canzonetta.

Catullus 63 treats of a subject that wouldn’t be out of place in an Almodóvar film: a young man, Attis, a devotee of the cult of Cybele, enters a trance and emasculates himself:

Super alta vectus Attis celeri rate maria
Phrygium ut nemus citato cupide pede tetigit
adiitque opaca silvis redimita loca deae,
stimulatus ibi furenti rabie, vagus animis
devolvit ili acuto sibi pondera silice.

Aside from its rather provocative theme, what marks this poem out is its driving rhythm:

⏑⏑–⏑–⏑––||⏑⏑–⏑⏑⏑⏑×

This rhythm is known as the Galliambic, and the first half (before the caesura — marked ‘||’) is also known as the Anacreontic. The Anacreontic rhythm can be considered as the result of anaclasis (inversion) of the middle two syllables of an Ionic dimeter:

⏑⏑––|⏑⏑–– becomes ⏑⏑–⏑|–⏑––

Now, if you go back and read my old teaser post for this concerto, you’ll see I discuss the patterns of bell ringing, which are based on swapping values in a series. The transformation from the Ionic dimeter to the Anacreontic follows the same technique (albeit in a fairly limited fashion).

The second source is the canzonetta Vi ricorda o boschi ombrosi  from Monteverdi’s L’Orfeo:

Here is the same passage in modern notation:

The pervasive rhythm of this passage is again the Anacreontic:

 ⏑⏑–⏑–⏑––

I had been keen for a while to play with classical rhythms, and this observation prompted me to start playing with the technique of anaclasis.

The opening passage of this movement doesn’t apply this technique to the Ionic dimiter, but rather to an Anapaestic rhythm:

⏑⏑–|⏑⏑–

After anaclasis, this becomes the following rhythm:

⏑⏑⏑–⏑–

Join the two rhythms, and you get this:

⏑⏑–|⏑⏑–|⏑⏑⏑–⏑–

This is the rhythm of the opening phrase of the Final of my concerto:

In addition to introducing an important rhythmic technique, this opening passage also sets out two other important aspects of the movement:

1. The anaclastic rhythm cuts across the barline (the A♯ quavers tied from b.3 to b.4) giving a syncopated accent;
2. The melodic material is derived from triads on C and F♯, which lie a tritone apart.

The entire first phrase shows how these three ideas are developed:

This brief opening fanfare is played in the oboe and bassoon, and leads into the rondo theme at [A]:

The first eight bars of this theme are based around the Anapaestic dimeter rhythm already explained, but with a small variation in the second foot. The following four bars, in 3/4, oppose a straight Ionic dimeter with its Anacreontic variant. This material maintains the polytonal nature of the opening: the strings play a vamp rhythm alternative between C and F♯ chords every two beats — even after the change to 3/4 —, and the thematic material meanders between these two tonal centres:

This material is interrupted with a harsh outburst in the strings, again varying the Anacreontic rhythm across an interval of a major 7th, which is then picked up by the oboe in the inversion of that interval: an minor 2nd, leading back into the rondo theme, which is rounded off with a descending variant of the broken chords that opened the movement.

Episode I at [E] takes the ideas of the rondo theme and explores them in a different context. The alternating chords are each moved by a semitone, from C and F♯ to C♯ and F. The vamp bass remains, but the upper strings now play counterpoint above it, rather than pizzicato, and the solo material is a duet between oboe and bassoon. The technique of anaclasis appears again, this time transforming a dactylic dimeter (which is not explicitly heard):

–⏑⏑|–⏑⏑ becomes –⏑–⏑⏑⏑

This episode leads straight back into the rondo theme at [F], which is this time finished with arpeggi in the low strings, which recall the solo material at [E].

Episode II leaves behind anaclastic meters, and explores Aeolic rhythms instead.

The core rhythm of Aeolic meter is the choriamb:

–⏑⏑–

This basic unit is extended by the addition of syllables before and after. The syllables before are anceps (either long or short), while those after tend to alter breve, longum. For instance, the rhythmic colon known as the Hipponactean looks like this:

⏓⏓ –⏑⏑– ⏑–×

In this episode, I decided to work freely with the principles of Aeolic rhythm, rather than adopting a preexisting verse form. Here is the resulting rhythm:

–– –⏑⏑– ⏑–⏑–
–– –⏑⏑– ⏑–⏑–
–– –⏑⏑– ⏑–
⏑⏑ –⏑⏑– ⏑––

In each of these lines the central Choriamb can be seen clearly.

This is the first episode in which the bassoon is the only soloist, and the first to move away from tonality. Rather than diatonic scales, the melodic and harmonic material is drawn from a scale that Messiaen would have described as the 2nd Mode of Limited Transposition, and which is also known as the octatonic. This is made of alternating tones and semitones.

The bassoon explores this scale, while the upper strings play diminished triads — the chord that forms if you take alternate notes from this scale. As in the rondo theme, there is an ambiguity between 2/4 and 3/4 meter, but this time it is the string figurations that change:

The material of this episode is played three times:

1. Bassoon solo with upper string triad accompaniment;
2. Oboe solo, bassoon counterpoint in diminished arpeggi, upper string accompaniment with cello bassline;
3. Oboe and bassoon have the melody, the upper string triads are spaced by octaves, the double bass joins the bassline.

The material then dissolves until only stratospheric violin and abyssal double bass are left. At this point a solo violinist picks up with the material first heard in the interruption to the initial rondo theme, which then leads into a statement of this theme in solo violin and pizzicato viola at [J]:

With the soloist played at such a high pitch, and no harmonic accompaniment, this material sounds very different from its initial statement. The material is then picked up in both violin parts (tutti), with accompaniment from all the lower strings, but still no harmony, and we then then move into the next episode at [L].

The rhythm of Episode III is again Aeolian. A feature of Aeolian rhythms is that the central Choriamb can be expanded, either by full repetition or with Anapaests (which are equivalent to a Choriamb with the first syllable missing). This passage uses Choriambic expansion, moving between Glyconics:

–⏑ –⏑⏑– ⏑–

And their expanded equivalent, the Asclepiad:

–⏑ –⏑⏑– –⏑⏑– ⏑–

The combination Glyconic, Asclepiad, Glyconic, Asclepiad is known as the Fourth Asclepiad, and is used by Horace in his Ode 3.9:

–⏓ –⏑⏑– ⏑×
–⏓ –⏑⏑– –⏑⏑– ⏑×
–⏓ –⏑⏑– ⏑×
–⏓ –⏑⏑– –⏑⏑– ⏑×

Donec gratus eram tibi
nec quisquam potior bracchia candidae
ceruici iuuenis dabat,
Persarum uigui rege beatior.

The rhythm I use for this section is slightly different, being composed of two Glyconics followed by an Asclepiad:

–⏑ –⏑⏑– ⏑–
–⏑ –⏑⏑– ⏑–
–⏑ –⏑⏑– –⏑⏑– ⏑–

Also, unlike Horace’s practice, I chose to use a short value on the second value of each line, and to keep the final value long; this keeps each line absolutely symmetrical, which adds to the character of this episode.

The melodic material for this episode is based entirely on whole-tone scales, alternating each bar between the two possible transpositions of this scale. The solo material makes a lot of the major 3rd that emerges from this scale, while the accompaniment, spaced in major 3rds, traces consecutive notes.

This episode falls into four sections:

1. Melody in the oboe, scales in violins;
2. Melody in the bassoon, scales in viola and cello;
3. Melody in violin II and viola, harmonics in cello and double bass, scales in oboe and bassoon;
4. Scales in oboe, bassoon and upper strings, harmonics in cello and double bass, then inverting roles with the upper strings playing very high notes and the cello and bass playing scales.

After these discursions into non-diatonic territory, we return at [N] to the final statements of the rondo theme. This time it is stated in the bassoon,  and is fully harmonised.The interruption from the first statement reappears here, with the oboe’s lead-in slightly altered, and then the theme reappears in counterpoint at [P], first in the bassoon with bar-spaced oboe arpeggi, then at b.297 in the oboe with constant bassoon arpeggi. These arpeggi take over at b.305 in both soloists and upper string, leading into the final statement of the theme at [Q], in both oboe and bassoon, with the string pizzicati replaced with arpeggi:

At b. 321 the soloists abandon the rondo theme, picking up the movement’s opening material, and are joined by the entire orchestra playing this fanfare at b.329, before the movement closes with exact material that opened it, but across the whole ensemble:

I have to confess to feeling slightly ambivalent about this movement. It is unquestionably a crowd-pleaser, and I have a feeling it’s good fun to play, but its very richness in tunes and compelling rhythms raise nagging feelings that it’s rather superficial and not serious music. Perhaps the analysis on this page is something of an apologia for it: an attempt to show that there are actually plenty of clever ideas behind its appealing tunefulness and vampish character. Or perhaps I should just relax and enjoy it!

(*Please read my note on copyright.)

(For those unfamiliar with serialism, and the 12-tone technique in particular, it is a method for producing musical — typically pitch — material by taking a list of values as a starting point. Various transformations can then be applied to generate new sequences. The multiplicity of different sequences provides variation, whilst their relationships back to the original series can give a sense of repetition and unity in the resulting music.)

Let’s consider 12-tone serialism.

A prime row can be considered as a mapping function P from a position to a pitch.

If we have a row [0, 3, 5, 8, 11, 1, 6, 10, 4, 9, 2, 7], then we can define P as follows:

P(0) => 0 
P(1) => 3 
P(2) => 5 
P(3) => 8 
P(4) => 11 
P(5) => 1
P(6) => 6
P(7) => 10
P(8) => 4
P(9) => 9
P(10) => 2
P(11) => 7

On this basis, we can write a JavaScript function prime which will take an argument n and return the appropriate pitch class name. (You can play along by pasting the code samples into the JS console in your browser).

var prime = (function () {
  var p = [0, 3, 5, 8, 11, 1, 6, 10, 4, 9, 2, 7];
  return function(n) {
    return p[n % 12]; // if a value of 12 or above is given, start from 0 again
  };
}());
prime(1); // => 3

prime(4); // => 11

(I’ve used a module pattern here to instantiate the variable p just once, and keep it hidden from the external scope.)

I can also write another function getPitches which will take a mapping function and apply it to an array [0..11]:

var getPitches = (function () {
  var d = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11];
  return function (callback) {
    return d.map(function(n) {
      return callback(n) % 12; // if the result is 12 or above, transpose down an octave
    });
  };
}()); 

getPitches(prime);
// => [0, 3, 5, 8, 11, 1, 6, 10, 4, 9, 2, 7]
// or
getPitches(function(n) { return prime(n); });
// => [0, 3, 5, 8, 11, 1, 6, 10, 4, 9, 2, 7]

We can now retrieve transformations of the row.

To get transpositions, re feed in prime(n) + x:

getPitches(function(n) { return prime(n) + 1; });
// => [1, 4, 6, 9, 0, 2, 7, 11, 5, 10, 3, 8]

getPitches(function(n) { return prime(n) + 4; });
// => [4, 7, 9, 0, 3, 5, 10, 2, 8, 1, 6, 11]

To get the Inversion row, we use 12 - prime(n):

getPitches(function(n) { return 12 - prime(n); });
// => [0, 9, 7, 4, 1, 11, 6, 2, 8, 3, 10, 5]

getPitches(function(n) { return 12 - prime(n) + 3; });
// => [3, 0, 10, 7, 4, 2, 9, 5, 11, 6, 1, 8]

To form the Retrograde we use prime(11 - n):

getPitches(function(n) { return prime(11 - n); });
// => [7, 2, 9, 4, 10, 6, 1, 11, 8, 5, 3, 0]

getPitches(function(n) { return prime(11 - n) + 3; });
// => [10, 5, 0, 7, 1, 9, 4, 2, 11, 8, 6, 3]

(The discrepancy between subtracting from 12 for the Inversion and 11 for the Retrograde is because we expect the Inversion to start on the same pitch, while the Retrograde moves the starting pitch to the end.)

And of course we can get the Retrograde Inversion with 12 - prime(11 - n):

getPitches(function(n) { return 12 - prime(11 - n); });
// => [5, 10, 3, 8, 2, 6, 11, 1, 4, 7, 9, 0]

getPitches(function(n) { return 12 - prime(11 - n) + 3; });
// => [8, 1, 6, 11, 5, 9, 2, 4, 7, 10, 0, 3]

In addition to these transformations, we can rotate the row (so, for instance, we start with the third value in the series):

getPitches(function(n) { return prime(n + 2); });
// => [5, 8, 11, 1, 6, 10, 4, 9, 2, 7, 0, 3]

And we can also experiment with multiplication:

Multiplying the argument passed into prime viz prime(n * x will jumpt between elements in the original series. If the multiplier is a factor of 12, then we will get a result that repeats a subsequence of the original; if it’s not a factor, then we will get a reordering:

getPitches(function(n) { return prime(n * 2); });
// => [0, 5, 11, 6, 4, 2, 0, 5, 11, 6, 4, 2]

getPitches(function(n) { return prime(n * 3); });
// => [0, 8, 6, 9, 0, 8, 6, 9, 0, 8, 6, 9]

getPitches(function(n) { return prime(n * 4); });
// => [0, 11, 4, 0, 11, 4, 0, 11, 4, 0, 11, 4]

getPitches(function(n) { return prime(n * 5); });
// => [0, 1, 2, 8, 4, 3, 6, 7, 11, 9, 5, 10]

getPitches(function(n) { return prime(n * 6); });
// => [0, 6, 0, 6, 0, 6, 0, 6, 0, 6, 0, 6]

getPitches(function(n) { return prime(n * 7); });
// => [0, 10, 5, 9, 11, 7, 6, 3, 4, 8, 2, 1]

getPitches(function(n) { return prime(n * 8); });
// => [0, 4, 11, 0, 4, 11, 0, 4, 11, 0, 4, 11]

getPitches(function(n) { return prime(n * 9); });
// => [0, 9, 6, 8, 0, 9, 6, 8, 0, 9, 6, 8]

getPitches(function(n) { return prime(n * 10); });
// => [0, 2, 4, 6, 11, 5, 0, 2, 4, 6, 11, 5]

getPitches(function(n) { return prime(n * 11); });
// => [0, 7, 2, 9, 4, 10, 6, 1, 11, 8, 5, 3]

getPitches(function(n) { return prime(n * 12); });
// => [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

Note the following properties of these series:

2. Maps to 6 pitches, repeated twice
3. Maps to 4 pitches, repeated thrice
4. Maps to 3 pitches, repeated four times
5. Remaps all pitches
6. Maps to 2 pitches (the fact that they are 0 and 6 is a propert of the Prime row, rather than this ordering)
7. Remaps all pitches, 0-based Retrograde of 5
8. Maps to 3 pitches, 0-based Retrograde of 4
9. Maps to 4 pitches, 0-based Retrograde of 3
10. Maps to 6 pitches, 0-based Retrograde of 2
11. 0-based Retrograde of Prime
12. Degenerate case: maps to just one pitch

Feeding in prime(n) * x remaps the pitches, rather than their ordering:

getPitches(function(n) { return prime(n) * 2; });
// => [0, 6, 10, 4, 10, 2, 0, 8, 8, 6, 4, 2]

getPitches(function(n) { return prime(n) * 3; });
// => [0, 9, 3, 0, 9, 3, 6, 6, 0, 3, 6, 9]

getPitches(function(n) { return prime(n) * 4; });
// => [0, 0, 8, 8, 8, 4, 0, 4, 4, 0, 8, 4]

getPitches(function(n) { return prime(n) * 5; });
// => [0, 3, 1, 4, 7, 5, 6, 2, 8, 9, 10, 11]

getPitches(function(n) { return prime(n) * 6; });
// => [0, 6, 6, 0, 6, 6, 0, 0, 0, 6, 0, 6]

getPitches(function(n) { return prime(n) * 7; });
// => [0, 9, 11, 8, 5, 7, 6, 10, 4, 3, 2, 1]

getPitches(function(n) { return prime(n) * 8; });
// => [0, 0, 4, 4, 4, 8, 0, 8, 8, 0, 4, 8]

getPitches(function(n) { return prime(n) * 9; });
// => [0, 3, 9, 0, 3, 9, 6, 6, 0, 9, 6, 3]

getPitches(function(n) { return prime(n) * 10; });
// => [0, 6, 2, 8, 2, 10, 0, 4, 4, 6, 8, 10]

getPitches(function(n) { return prime(n) * 11; });
// => [0, 9, 7, 4, 1, 11, 6, 2, 8, 3, 10, 5]

getPitches(function(n) { return prime(n) * 12; });
// => [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

Note the pitch-sets that these values of x map to:

2. Whole-tone scale
3. Diminished 7th
4. Augmented triad
5. Full chromatic remapping
6. Tritone
7. Full chromatic remapping, Inversion of 5
8. Augmented triad, Inversion of 4
9. Diminished 7th, Inversion of 3
10. Whole-tone scale, Inversion of 2
11. Chromatic scale, Inversion of Prime
12. Degenerate case: unison

From these two multiplicative transformations, we have new ways to define Inversion and Retrogression, and also a realm of other possible transformations. We can write something like this:

getPitches(function(n) { return prime(n * 5 + 8) * 7 + 4; });
// => [8, 1, 10, 5, 9, 7, 3, 2, 4, 11, 6, 0]

and know that the material is still explicitly derived from the original series.

These examples are just a few first examples of the generative power of a few simple lines of JavaScript. Next time I want to investigate what happens when you reflect the position/pitch axis, and introduce a way to deal with negative numbers, but this is enough for one evening!

You can find the source of this project at https://github.com/bnathyuw/Hateoas-Console

Introduction

RESTful web architecture is becoming increasingly influential in the design of both web services and web sites, but it is still very easy to produce half-hearted implementations of it, and the tools that exist don’t always help.

In this project, I want to address this problem by building a new REST console that will:

• Reward good implementations by making it easy to take advantage of all their RESTful features;
• Help improve less good implementations by exposing their shortcomings.

Basic principles of a RESTful interface

Richardson and Ruby (2007 pp. 79 ff.) present a good analysis of RESTful interface design. Drawing on Fielding (2000 s. 5), but with a focus on actual practice, they identify four key principles or Resource-Oriented Architecture:

1. Addressability;
2. Statelessness;
3. Connectedness;
4. Uniform Interface.

Addressability means that any resource in the application that a consumer could want to know about has at least one URI. This criterion is fairly coextensive with Fielding’s Identification of Resources requirement.

Statelessness means that every request should contain all the information needed for its processing. This overlaps with Fielding’s requirement that messages be self-descriptive, and that hypermedia be the representation of application state.

Connectedness means that each resource representation should give addresses of all related resources. The most effective way to ensure connectedness will often be to produce an entry-point resource, from which it is possible to navigate to all other resources. This furnishes the other part of Fielding’s requirement for hypermedia as the engine of application state.

Uniform Interface means that all resources can be manipulated in the same way. For web services, this almost invariably means using the HTTP verbs, viz DELETE, HEAD, GET, OPTIONS, POST, PUT &c. This principle supports Fielding’s self-description criterion, and specifies the means of manipulation of resources.

Most REST consoles are fairly successful in accommodating principles 1, 2 and 4, but fail significantly in accommodating principle 3. Under Fielding’s terminology, existing REST consoles give little support for hypermedia as the engine of application state (HATEOAS).

Existing REST consoles

There exist several good consoles for manually consuming RESTful services. These include:

• Simple REST Client for Chrome;
• REST Client for Firefox;
• apigee.

All of these clients work on a similar model: you enter a URI in the address box, choose an HTTP verb and click a button to send the request. You also have the option of adding headers and a request body. The headers and content of the response are then displayed on screen for the user to inspect.

How these consoles support the REST principles

Addressability

Addressability is a core notion in these consoles: the address box is a primary part of the UI, and you have to enter something here in order to make a request.

Statelessness

Statelessness is perhaps the easiest of the four principles to achieve, as the consoles operate on a request-response model.

In fact, what is useful in a console is the very opposite of statelessness: the console should be able to remember your preferences so that you do not have to enter them for each request.

With a significant exception discussed below, all three consoles do a fair job of remembering your choice of headers from one request to another, which takes some of the burden off the user. Apigee and REST Client for Firefox are also able handle OAuth authentication, which is a nice feature.

Connectedness

None of the consoles deals successfully with connectedness. If you want to follow a link from the response, you have to copy the resource URI into the address box and submit another request.

Apigee differs from the other two consoles in having a side panel which lists the principle URI schemata for the service under test. This initially seems like a helpful feature, but has several unfortunate consequences:

• Apigee uses WADL to create its directory of links. This encourages a return to the RPC-stle of service architecture, which thinks of a web service as being made up of a limited set of discrete endpoints, each with a particular purpose, rather than an unlimited network of interconnected resources which can be manipulated through a uniform interface.
• As the endpoints are listed in the directory panel, it is less obvious when a resource does not contain links to related resources.
• Apigee has no way of filling in variable parts of a URI. If, for instance, you click me/favourites/track_id (PUT), it enters https://api.soundcloud.com/me/favorites/{track_id}.json in the address box. You then have to replace {track_id} with the specific track ID you are interested in. This is of course no help if you don’t know which track you want to add to your favourites!
• Each endpoint is listed with a .json suffix, no matter what format you have just requested. Also, any request headers you have filled in are forgotten when you click on a new endpoint.

These shortcomings not only make the console frustrating to use, but also encourage non-connected, RPC-style architectural decisions.

Uniform Interface

As with Addressability, the Uniform Interface is at the core of these consoles. The HTTP verb selector is prominent in each UI, and it is easy to switch from one to another.

Apigee supports GET, POST, DELETE and PUT, Simple REST Client for Chrome adds support for HEAD and OPTIONS, and REST Client for Firefox adds support for TRACE, as well as several more obscure verbs.

What none of these consoles does is make any attempt to figure out what representation of a resource should be submitted in a POST or PUT request body. This is particularly surprising in Apigee, as this information should be available in the API WADL document.

Conclusion

There are close points of comparison between a REST console and a web browser: each is designed to make requests from a particular URI using one of a small number of HTTP verbs, and then display a representation of that resource to the user. What makes a web browser so powerful — and indeed was one of the founding principles of the internet — is that the user can click on links to get from one page to another. When you the primacy of the clickable link to the success of browsers it becomes all the more puzzling that REST consoles do not implement this functionality.

The Project

Basic principles

The purpose of this project is to attempt to address some of the shortcomings of the currently available REST consoles, while retaining their good features:

• The basic format of the existing consoles is successful: an address box, and verb chooser, and a send button;
• Rendering all details of the response is also vital; REST Client for Firefox gives you choice of viewing raw and rendered data, which is a nice additional feature;
• The client should support as wide as possible a range of HTTP verbs, encompassing at least GET, POST, PUT, DELETE, OPTIONS, HEAD;
• The ability to remember headers is very useful and should be kept, especially when clicking on a link;
• OAuth integration is a nice feature and worth implementing if possible;
• It would be very useful for the console to make a reasonable attempt at figuring out the response body format for PUT and POST requests;
• Reliance on a WADL document encourages unRESTful thinking and should be avoided.
• All appropriate links in the response body should be identified, and it should be simple to make further requests and to explore the API by clicking on them.

Implementation decisions

I decided to implement this project in HTML and JavaScript, as this seemed the most portable platform. I am working on the assumption that the finished product will be a chrome extension, as this lets me make some simplifying assumptions about the capabilities of the browser environment, and may also help solve some security issues.

References

• Fielding, Roy Thomas (2000). Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine.
• Richardson, Leonard; Ruby, Sam (2007). RESTful Web Services. O’Reilly Media.

Scenario

The scenario Troy describes is for a site that will perform a security scan of your website, and then show a report of the result. Addressability is an important concern, as once you have the results of the scan, you may want to forward them to other people.

Troy discusses two methods for including the URL to scan:

1. Include it in the hierarchical part of the URL (ie, the part after http: and before ?, eg http://asafaweb.com/scan/troyhunt.com/Search)
2. Include it in the query string, eg http://asafaweb.com/scan?url=troyhunt.com/Search.

He favours the second approach for practical reasons.

A RESTful approach

Troy’s article approaches this question from the point of view of addressability, rather than resource design, and makes a sensible recommendation given the basic premisses; however, the scenario he outlines presents a good opportunity to do a bit of resource design analysis, which can lead us to an even better answer.

First then, let’s think about the type of resource we’re dealing with.

I think it is fair to make a few assumptions about the scan resource and the application that generates it:

• It will take some time to perform the scan;
• It will take a fair amount of computing resources to perform the scan;
• The scan will be accurate for the point in time at which it was created; a subsequent scan of the same URL may generate a different result;
• It may be interesting to compare scans over time.

From these assumptions we can draw a few conclusions:

• A scan is an expensive resource to create, and will have a series of different statuses over its lifetime; this means we are looking at a transactional resource model here;
• As a URL can be scanned more than once, it is not on its own a sufficient identifier of any scan.

If we follow these conclusions, we can make a sketch of the process of performing a scan:

1. Trigger the scan

We make a POST request with the details of the scan we want:

POST http://asafaweb.com/scans
{ "url": "http://troyhunt.com/Search", "options": {…} }

Note that we are POSTing to /scans; this request will create resource subordinate to that collection. Also, as we are making a POST request, we can include further information about the scan we want, perhaps indicating which criteria we are interested in and what level of detail we require; I have indicated this possibility by including an options parameter.

The server responds not by showing us the results of the scan — they haven’t been produced yet —, but by telling us where to look for the results:

201 Created

http://asafaweb.com/scans/{xyz}

2. Check the scan URL

We can go and check this URL straight away by performing a GET:

GET http://asafaweb.com/scans/{xyz}

As the scan is still running, we don’t see the results, but rather a representation of a scan that is still in progress:

200 OK 
{ "scan": {
  "status": "in progress", 
  "url": "http://troyhunt.com/Search",
  "created": "2011-09-18 11:57:00.000",
  "options": {…}
} }

Indeed, if there are a large requests for scans, Troy may have to implement a queueing system, and our scan may have a status of "queued" until it can be processed; we could even cancel a scan by PUTting a representation with a status of "cancelled" to its URL, or perhaps simply by issuing a DELETE request.

3. Retrieve the scan

A little while later, the scan has completed. Perhaps we keep performing a GET on its URL until it’s done; perhaps we have submitted an email address in the initial POST, and have now received email notification that it is ready.

We perform another GET to see the results:

GET http://asafaweb.com/scans/{xyz}

And the server responds:

200 OK 
{ "scan": {
  "status": "complete",
  "url": "http://troyhunt.com/Search",
  "created": "2011-09-18 11:57:00.000",
  "options": {…},
  "results": {…}
} }

We can now send the URL http://asafaweb.com/scans/{xyz} to  other people, and they will see the same results. The server doesn’t have to rescan the site, so retrieving these results can be a quick, inexpensive operation.

4. Search for scans

Throughout this example, I have used {xyz} to indicate the unique identifier of the scan. I have deliberately not given details of what this identifier might be. However, as I said earlier, the URL to scan is not a sufficient identifier, as we want to allow the possibility of scanning the same URL more than once. This identifier could include the URL, but this may not be the ideal solution, both for the technical reasons that Troy indicates in his article, and because this will produce very long identifiers, where we could probably make do with short strings of characters.

The result of this is that we have a system that is eminently addressable, but which uses identifiers that bear an opaque relationship to the scanned URL, and fails the findability criterion. I can easily send a URL like http://asafaweb.com/scans/f72bw8 to a friend, but if they do not have that address, they have no way of guessing that this is the address of a scan of my site.

To remedy this, we can implement a search interface. We already have an address for the entire collection of scans, viz /scans, so  now we can just refine the response to a request of this URL with a query parameter:

GET http://asafaweb.com/scans?url=http://troyhunt.com/Search

The server can then respond with a listing of all the scans that meet these criteria:

200 OK
{ "scans": {
  "url": "http://troyhunt.com/Search",
  "results": [
    {
      "status": "complete",
      "created": "2011-09-18 11:57:00.000",
      "link": {
        href: "http://asafaweb.com/scans/f72bw8"
      }
    }, 
    {
      "status": "complete",
      "created": "2011-08-28 17:36:24.023",
      "link": {
        href: "http://asafaweb.com/scans/89ew2p"
      }
    }, 
  ]
} }

Each result has a link to its location, so all results can be retrieved at any time.

By recognising that our scans are resources that can be searched, and by providing a means to perform that search, we have restored findability to our interface. Also, the fact that our search criterion is a refinement of a more general request, and thus appears in the query string, means that we arrive at a very similar conclusion the one Troy reaches in his article, but this time for reasons based on resource design, rather than practicality.

Applicability to web sites

I have given all my examples in JSON, as it offers a concise and easy-to-read format for technical discussions. However, all of this discussion would work equally well with HTML web pages:

1. The user fills in and submits a form to request a scan, and is redirected to the scan page;
2. The scan page shows a message telling the user the scan is in progress;
3. After a while a page refresh reveals the results of the scan, and the user can send the page URL to their contacts;
4. The /scans page offers a search form into which the user can enter their URL and retrieve a list of all the dated scans for that location.

A couple of the implementation details will differ, because of the limited number of HTTP verbs and status codes that browsers can deal with, but the principles are exactly the same.

The structure of this movement is fairly simple, building up a contrapuntal structure over a double-bass ostinato. Click here to have a look at the score or listen to the live recording*.

The ostinato itself is made of two 4-bar phrases, each repeated. Each phrase has 12 notes: each of the notes of the pentatonic scale, although the sequence is not used as a row. The rhythm alternates between 3-quaver and 2-quaver beats to give a distinctive rhythmic identity to the whole movement.

Over this ostinato, the bassoon and orchestra conduct a dialogue which builds up a contrapuntal texture. High in my mind at the time of writing this were Kerry Andrew‘s wonderful performances of folk songs, delivered live with just a loop console for accompaniment. I love the textures she can create by laying down one part over another, and the way the piece slowly comes together, and wanted to explore this idea with an ensemble, acoustic piece. Another image that springs into my mind with this music is that of a 3D printer, which can create a solid artefact by laying down layer upon layer of 2-dimensional material.

The movement is divided into 16-bar sections. In each, the bassoon plays two 4-bar phrases, each of which is then repeated immediately in the strings. In the following section, the string part that has already been layed down is played again, and the new material is played by the next part up. This means that the cellos repeat their material 4 times, whereas the first violins only get one exposition.

This cumulative structure is repeated twice, with different material. In the first, the material of the ostinato is performed first, and played by the cellos (as well as continuing in the double bass); in the second part, this material is saved for the last entry, and appears in the first violins. As each section builds up, the dynamic increases; at the end of Section 1 we drop back to 16 bars of ostinato played pianissimo in the double bass; at the end of Section 2 we hear the ostinato played in octaves by all the performers, crescendo to fortississimo, and which point the movement stops dead.

The material is fairly straightforward. Some phrases are derived from the ostinato, and others play with chains of intervals. My intention was that there should be a range of different syncopations, so as to achieve a rhythmic counterpoint alongside the melodic counterpoint. I made no attempt to inject any harmonic meaning into the parts, but made sure there was a good range of tessitura so as to keep the identities of the parts fairly distinct.

Note: if you would like to listen to a recording of this performance, please get in touch and I can send you a link.

(*Please read my note on copyright.)

• The lower strings play 13 permuted repetitions of a simple, 12-bar phrase
• The oboe and bassoon play 12 phrases of different lengths, in different orders

In this post I will explain how the musical material of the solo parts is derived, and discuss a few other final details. You can also click here to read the full score of the movement and listen to the live recording*.

The melodic material is based on a 28-member interval row generated by rolling a die:

3 3 4 5 6 6 1
1 5 6 4 2 5 6
6 3 2 1 1 2 6
1 3 1 3 5 5 5

In writing the material for each section, I followed a simple set of rules:

• The first pitch is always a D
• Each new note is found by moving either up or down by the corresponding interval in the row
• Any octave transposition is permitted
• Hence in the oboe part, starting from d´, and with an interval of 3, the next note can be b, f´, b´, f´´, b´´or f´´´
• Any note or succession of notes can be repeated, including sequences (eg u–v–w, u–v–w–x, u–v–w–x–y, u–v–w–x–y–z)
• The pitch material for each section is derived separately, although certain techniques and motifs recur

The first two phrases of the oboe part illustrate these principles:

The first phrase uses the first 7 members of the interval row in sequence: 3 3 4 5 6 6 1. The second phrase repeats the notes of the first phrase, adding one more note, again generated using the interval row.

Another illustration can be found from a bassoon passage half-way through the movement:

In this passaged again the material is generated from the beginning of the sequence, but the process is drawn out by the repetition of sequences of notes.

As the interval row is fairly large, it is only used in the 9, 10, 11 and 12 unit sections. In sections 1, 2, 3 and 4, only 7 members (one line) of the row are used for each section, and in 5, 6 and 7, 14 members (two lines) are used. Section 8 is silent.

The other patterns in the material are that in odd-numbered sections the oboe and bassoon parts are inversions of each other, while in the even-numbered sections they are rectus. Sections 1, 4, 6, 7, 9 and 12 are lyrical in nature, and sections 2, 3, 5, 8, 10 and 11 are more mechanistic (8 trivially so).

Here then is a brief analysis of each of the sections, following their order in the oboe part:

Section 12

The longest passage in the movement, the material in this section is lyrical, covering a wide tessitura. The passage falls loosely into two sections, the first  characterised by sustained notes which lead into arpeggio-like flourishes; the second by repeated notes leading into material which meanders around a small cell of pitches.

The material from this section recurs throughout the movement.

Section 9

This section is a reworking of the material in Section 12. It is rhythmically simpler and less discursive. Gestures from the solo material are picked up in the violins and form part of their ostinato (see below).

Section 6

This section picks up material from Sections 9 and 12 and develops it a little further.

Section 3

The first ‘mechanistic’ section in the oboe. This introduces the technique of gradually adding to a cell of pitches.

Section 2

This is the one point of true coincidence in the movement. At the beginning of the movement, Section 12 in the oboe is accompanied by Section 2 in the bassoon. At this point, this relationship is reversed.

The material is extremely simple: just a falling sequence notes. The number of beats between the notes decreases over the course of the 4 bar section.

Section 5

Section 5 is structurally fairly simple: a 2-bar phrase is repeated for two different sets of pitches. It’s then split in half, and each half is repeated independently. The opening motif is then repeated on its own.

Section 8

Section 8 is silent, primarily to give the soloists a chance to get their breath back!

Section 11

Section 11 is highly mechanistic. The excerpt of bassoon music above is taken from the beginning of this section, and illustrates the way the material is generated. Its nature is fairly relentless, and had to be reworked a couple of times to make sure the performers had enough space to breathe.

This is also one of the moments of minor coincidence in the movement, as the oboe starts this section 6 bars after the bassoon. This makes this passage one of the more obviously canonic parts of the movement (inverted of course, as 11 is an odd number), and the driving rhythms of the material make this the climax of the movement.

Section 10

Section 10 is fairly simple, and similar to Section 5: a phrase is repeated and then deconstructed.

Section 7

Section 7 provides another explicitly canonic passage in this movement, as the oboe starts this section 8 bars after the bassoon. The section is divided in two, and the second half is an exact inversion of the first. Because this division happens after bar 7, and because the oboe and bassoon parts are inversions of each other, this means that the second half of the section in the bassoon is in rectus canon with the first half of the section in the oboe, with a delay of one bar.

I am particularly fond of this section because of this canonic cleverness, so here are the bassoon and oboe parts on their own to clarify the structure:

Section 4

Section 4 takes the movement’s opening motif as its sole source of material, and leads into…

Section 1

The final coincidence of the piece, oboe and bassoon play Section 1 simultaneously. The material again uses the opening motif, so in the oboe it follows directly from Section 4. As 1 is an odd number, the parts are inversions of each other, so they open away from middle d´.

Upper Strings

I have discussed the chaconne in the lower strings, which is made of 13 repetitions of a 12-bar phrase. The material in the upper strings is made of 12 repetitions of a 13-bar phrase, and uses entirely extended techniques: tapping the strings with the wood of their bows, playing the short lengths of string beyond the bridge, tapping the wooden body of the instrument, and playing notes with Bartók or snap pizzicato.

There are a few melodic elements in this material, principally echoes of the soloists’ material in Section 9, and I was keen on the idea of building a background soundworld, elements of which could then come into focus in the right context.

This movement is by far the most complex compositionally, and probably the most challenging to listen to, but I think that, despite all its complexities, it has a lyricism that works well within the structure of the whole work.

I also have a feeling that this movement would work well rewritten for oboe, bassoon and electronics. A project for another day!

Note: if you would like to listen to a recording of this performance, please get in touch and I can send you a link.

(*Please read my note on copyright.)

Since then I’ve kept a close eye on their work, so I was really keen to get to some performances in their 5th annual Opera Festival at Riverside Studios (which is also conveniently near Shepherd’s Bush, where I live).

I met my lovely friend V there at half past six, and we were treated to three entertaining, moving and thought provoking performances.

Catherine Kontz and Danny Standing’s Larvae was an effective piece of music theatre for baritone and radios performed in the lobby of the studios. A bit of humour, a bit of weirdness, and the odd dash of audience participation (both intentional and un-) made a fantastic introduction to the evening.

Tête à Tête have made quite a fetish for airing works in progress, sometimes in the very early stages of gestation. Robert Fokkens‘s Love Songs was presented as little more than a sketch, but already had a great sense of identity and purpose. Fairly predictably, the moment that stood out for me was the marriage scene, where Fokkens sets the priest’s homily as Anglican psalmody to an accompaniment on the melodica, which slowly gives way, with gentle insinuations on the drum kit, to a slow dance for the ‘happy couple’ before returning to the liturgical style for the pronouncement of marriage. Fokkens has a sure hand with the various genres he plays with, and the narrative uncertainties in this initial sketch should work themselves out as it’s developed further. (Bill did put out a plea for funding to develop this piece further, so anyone with £100k to spare should look no further!)

With four studio performances in one evening, it was tough choosing what else we wanted to see. Nick Owen and Gary Carpenter‘s Closing Schools for the Future had the most unlikely premise: a social policy research project cum opera based on the closure of a primary school in the Wirral. The texts were all genuine material: council minutes, excerpts from research papers, interviews with teachers, parents and stakeholders, and the performers were dressed unassumingly in suits and ties. What came out of it however was a funny and poignant study of an event which affected a community very closely. Whether poking affectionate fun at the conventions of policy documents (as citations flashed up on the screen in an overenthusiastic powerpoint slideshow), or examining the repercussions for children with physical or learning impairments (will they be left behind, or by some miracle or local planning encouraged to gain more independence), this performance managed to be both entertaining and moving. The final section, set to the sound of three iPhones running Brian Eno’s Bloom app was haunting, charming and slightly disconcerting.

The other involving aspect of the evening was the question and answer session that followed each of the seated performances. I think it’s really valuable to have a chance to discuss new music, and when one piece is very much a workshop, and other is so tied up in a community, it makes a lot of sense to follow them with a discussion. I feel I came away with a better sense of the pieces context, and I hope these discussions also help guide the developments of the pieces. There was even a threat of another opera on the closure of bus routes!

The first movement of my Concerto for Two Double Reeds is for oboe solo and orchestra; it builds on two ideas:

The first idea is stolen from György Ligeti, and it is to divide the chromatic scale according to the keys on the piano: the white keys form a diatonic scale, and the black keys form a pentatonic one. In this case, the white notes are given to the oboe, and the black notes to the orchestra.

The orchestra play their notes with two textures: sustained chords, and descending pizzicati passed from instrument to instrument. The five notes of the pentatonic scale are divided between the five parts: Violin I, Violin II, Viola, Cello, Double Bass in a succession of narrowing, then broadening spacings:

Throughout this sequence the second violins hold middle d´♯, which acts as a pivot for the other notes. Within the pentatonic scale, the first chord can be considered to be build on 5ths (A♯ – C♯ – D♯ – F♯ – G♯ is five successive degrees of the pentatonic scale), the second on 4rds, the third on 3rds, and the fourth on 2nds, so the spacing is entirely regular, albeit within an irregularly spaced scale.

The second idea is to base the oboe part, within the confines of the diatonic scale, around a repeating group of intervals. All the oboe material is based around a ladder, or tessellation, formed of rising perfect fifths and falling major seconds, a technique which acknowledges Messiaen’s modes of limited transposition, whilst doing pretty much the opposite!

Pushed much further this pattern would encounter black notes, but then again, pushed much further it would exceed the oboe’s range!

The resulting movement is in two sections:

In Section 1, the strings hold each, successively narrower, spacing of the pentatonic pitch set while the oboe plays increasingly florid, improvisatory material. For each chord the oboe plays three phrases of increasing length, followed by the pizzicato string motif.

The final, close-spaced pizzicato motif of Section 1 becomes the first motif in Section 2, which is for strings alone. The abandon the sustained chords, and just play the pizz motifs in reverse order. Finally, reach a 4-octave span of D♯s, which they play three times, ending fff to end the movement.

In workshopping this movement, we discussed various ways to notate the oboe passages. I had originally been fairly specific about which notes should be triplets, and about dividing the material into bars, but felt that this detracted from the rhythmic freedom the performer should have in interpreting the material. Rhuti’s performance brought a lyricism to this movement that went beyond what I had envisioned, and even elicited comparisons — unexpected, but not unwelcome — to  Delius.

Note: if you would like to listen to a recording of this performance, please get in touch and I can send you a link.

(*Please read my note on copyright.)

I owe a great debt of thanks to our fantastic soloists, Rhuti Carr and Andrew Watson, to the Handel Collection and their leader Irina Pakkanen, and to Edward Adams, whose conducting and oversight brought the performance together, and who first suggested I write the piece.

I have already posted a little analysis of the second movement of this piece, and I plan to post more in the coming days, along with some score excerpts and perhaps some audio samples. In the mean time, I would like to jot down a few general reflections:

• I was really fortunate to get feedback from Edward and Rhuti during the compositional process. I had early conversations with them about the shape of the piece, and we then ran two workshops while I was writing the work, which were invaluable in steering me towards writing more idiomatically for the oboe. (As an aside, it strikes me that this approach has certain similarities with Agile software development insofar as a dialogue is maintained between composer / programmer and performer / end user. A thought for another day.)
• Another piece of luck was that Andrew was able to step in as bassoon soloist. The original plan had been to write an oboe concerto, but the second movement was calling out for another soloist, and once I had a substantial bassoon part in that movement, it seemed a little unjust to make the performer sit aside for the rest of the piece! The third movement, which is the bassoonist’s showcase, is in part a solution to this problem.
• The other problem that the third movement attempts to solve is that the finale is completely stylistically incongruous. It started life as a little sketch which I played to Rhuti and Edward, and which they liked so much that the insisted I keep it in the piece. However, the transition from the atonal, rather austere second movement to the (poly)tonal, jaunty romp of a finale was really rather jarring, and needed something to act as a bridge. I hope that the syncopated, motoric rhythms and cumulative counterpoint of the third movement achieve this. The finale retains its original character, but I hope I’ve done something interesting with it, as well as showing I can write a good tune!
• Even after the workshops, a few points did arise during the rehearsals, particularly to do with the string writing, and it was really useful to be able to talk through them with Irina and agree a few revisions to bring the performance closer to what I had had in mind.
• Finally, I got the impression that the performers had fun playing the piece. Two moments particularly stick in my mind. First, about half way through the rehearsal of the third movement, the structure of the piece revealed itself to Irina, and I could see her face light up, and she turned to the orchestra and told them ‘Ok, I want to you stop counting bars and just listen to the bassoon, because whatever he plays, you repeat.’ The second moment that sticks with me is in the final movement, where I’ve given the double bass pizzicato slides from a very high note down as low as possible, and where I’m sure I caught the bassist exchanging grins with the viola section.