NetKernel News Volume 4 Issue 22

September 13th 2013

• Repository Updates
• Web Site Refresh
• Web Optimisation Techniques

Repository Updates

You knew it, we knew it, everyone knew it. Our website was past it.

This summer we dug deep and undertook a root-to-branch rewrite. I'm delighted to announce that the new site is live and performing very well.

http://www.1060research.com

Pretty much everything is new including moving to modern HTML5 "responsive design" using Bootstrap3 - meaning the same content now displays cleanly on large displays and dynamically adapts to small devices.

In addition to re-digging the technical foundations, we've also given some deep thought to our content.

I think we have been able to introduce the core value of ROC - its ability to radically transform software economics - and explain how ROC takes the implicit two-phase resolve/execute model of the Web and REST and makes it explicit and general. The irony of our story is that we were never motivated by technology for its own sake - its always been about changing the economics - and yet, it led us to discover a world of hugely significant technical breakthroughs too.

We've made the site more succinct and removed our historical attempts to boil the ocean and explain every last detail. For example, ROC is now explained in a short story-board showing its six scale-invariant elements.

Anyway, please take a look and let us have your thoughts and opinions. We're especially keen to add some new quotable quotes from real users. No one ever finishes a website but starting today we will keep delivering ongoing refreshes.

This release marks the start of a new stage for us. We're feeling confident and ready to reach out with a very compelling story and the hard-core concrete technology to back it up and deliver. We know ROC radically changes software economics - you tell us it does. Its time to tell the world that there's a better way...

Our new site uses all the available off-the-shelf tools/techniques NetKernel provides to deliver an optimised REST experience. It is very snappy and ticks all the boxes with the Google site analyser. Here's the key ways we achieved this...

RESTOverlay

All of the site's resources are wrapped by a RESTOverlay. The public REST paths are expressed as <simple> grammars that are mapped to active dynamic generated HTML composites using XRL recursion. Every channel(logical endpoint) provides user-side metadata for the RESTOVerlay. Here's an example of the mapping we use for the /products/ page...

The RESTOverlay is dead simple - you just wrap your endpoints with it and it picks up the metadata it needs off the <meta><rest/></meta> tags. The one tricky thing to remember is that it will externally generate the REST path grammar from the <simple> grammar and this must be different from the unique inner grammar of the endpoint - so here you can see we just use the trick of prefixing our inner grammar with uniqueInternal:.

As regards the actual RESTOverlay processing, using SHA1 Etags ensures that over the long-term a browser with a copy of the site in cache will report back its local copy's hash and, even if NetKernel has been rebooted, NK will automatically reply with a 304 response if the dynamic content is still the same.

Using <compress/> tells the RESTOverlay to do compression negotiation with the client and ensures that all the content is streamed in a minimum compressed format.

Automatic HTTP Cache Headers

Where we have static resources, such as images, css and javascript we use the HTTPBridge's feature of setting several HTTP cache directives based off one simple NK internal response header: HTTP_CACHE_EXPIRES_DELTA_SECONDS . Its easier to see an example...

or using NKF...

INKFResponse response=context.createResponseFrom(foo);
response.setHeader("HTTP_CACHE_EXPIRES_DELTA_SECONDS", "86400");

By setting HTTP_CACHE_EXPIRES_DELTA_SECONDS as your endpoint's NetKernel response header (note this is the NK response not HTTP response) the HTTPBridge calculates the absolute Expires time and sets this on the HTTP response. It also sets the Cache-Control with the following: public, max-age=86400.

All values are in seconds - so in this example, we're saying our static resources can be safely cached for 24 hours.

Lossless Image Compression

Finally, non-NetKernel related, it pays to run a lossless compression tool over your jpg/png images. We used jpegoptim and optipng and saw some images losslessly reduce by up to 70%.

One thing to note: it is a waste of resources to do compression negotiation on images, since they are already compressed and you're unlikely to get any further compression using gzip or deflate. So don't use the RESTOverlays <compress/> option for image resources (but do retain SHA1 Etags).