NetKernel News Volume 3 Issue 26

June 8th 2012

What's new this week?

• Repository Updates
• Update: NetKernel Quick Reference Guide v1.2
• ROC-aware URIResolver
• DPML - A very unusual language
• Review: Samsung Galaxy S3

Catch up on last week's news here

Repository Updates

The following updates are available in the NKEE and NKSE repositories...

• lang-dpml-1.18.1
  • fix to make switch accessor declared as a core dpml accessor with the tag <switch>
• nkse-visualizer-1.19.1
  • fix so that enterprise edition timing values would work properly in locales which use a comma as a decimal point.
  • robustness enhancement to catch any unanticipated exceptions when saving a trace so that even if something very bad happens a trace can still be sent to support.

Update: NetKernel Quick Reference Guide v1.2

The NetKernel Quick Reference Guide has had a spring clean and is now up to version 1.2. If you've not looked at it before, its a handy print-friendly document with quick references to all the core NK concepts, syntaxes, NKF API and commonly used libraries.

At any time, you can grab the current latest edition from the portal...

https://cs.1060research.com/csp/download/

and if you want to link to this specific version directly, its also available here...

http://resources.1060research.com/docs/2012/06/NetKernelQuickReference-1.2.pdf

ROC-aware URIResolver

Did you know that when you use XML (or other "Web-aware" technologies) which expect to have a URIResolver provided (for example XSLT, XQuery, RDF parsers etc etc) then our standard pattern of integration is to provide the technology implementation with a ROC-aware URIResolver implemented using the underlying INKFRequestContext.

What does this mean? Well it means that whenever a language or transformation tool calls its URIResolver it actually initiates a request into the current contextual ROC address space. Which means? Well, it means that any resources you have resolvable in your space are legitimate references in your scripts and/or transforms.

Once you understand this pattern then you can set up your application space with lots of powerful endpoints. Like for example having all web-resources directly resolvable by importing the http client... or file:/// resources... or, even, all your active:foooBaaa services... oh, and of course, since the resources are resolved in the ROC domain they'll acquire the opportunity to be cached for free.

Background Details

I was prompted to mention this since Geert Bormans, who is a long standing ROCer from back before NK3, rediscovered this potential earlier today.

Incidentally if you are using a Java library who's API accepts an instance of the fairly standard: javax.xml.transform.URIResolver you'll find that the xml:core library provides org.netkernel.xml.util.NKFURIResolver which requires a context object on its constructor. By setting up your tool with this URIResolver it then provides it with the whole of the ROC domain to work with...

(You'll also find in that package a similar utility class to implement an ROC aware org.xml.sax.EntityResolver and for good measure an org.w3c.dom.ls.LSResourceResolver).

DPML - A very unusual language

We released an update to the lang-dpml package to fix a bug in which the <switch> conditional was not correctly validating. This provided the context for today's short story and presents the opportunity to discuss why DPML is a very unusual language.

On face value DPML appears to have within it support for if, switch, log, throw, etc etc. The sorts of conditional logic and process control you'd expect in any language. But the truth is that DPML does not have any in-built functions at all. Nor indeed does it have any in-built types. Not even "int".

When you use DPML what you're doing is co-ordinating a series of resource requests. DPML's only "type" is the declarative request. When you write an <if> statement what actually happens is that the tag gets converted to a request to the active:if endpoint - provided as a service in the DPML language's rootspace.

If you want to extend the DPML language you can create your own endpoint and bind into the language with a tag declaration. The metadata of the target endpoint is used to construct a request based upon the tag used in your DPML code.

Now, I'm sure language scholars amongst you will be able to point out other examples of extensible languages. Not least in variants of LISP.

The next part is something I don't think any other language can claim. For, did you know that DPML is a "stateless language"? Well not quite, it contains just one single item of state - a "program counter" which maintains a reference to the location in the code which is currently being evaluated. But DPML holds no variable state!

"Hold on hold on! But you can do assignments to named variables!!"

Yes you can. But whenever any representation state is returned in a request it is assigned to that named assignment (variable) but in fact it lives inside an address space which is contextually scoped to the current execution. DPML variables are resources that live in ROC spaces.

If you've followed the discussion about Pass-by-Value spaces - you'll know we discovered an elegant way to turn push into pull. DPML simply takes this to the ultimate level. It says "all state is extrinsic" the excution state is a set of resources - all functions in the language will pull this state.

So now you see that if this is the underlying basis of DPML, it makes complete sense that all the language's functions are extrinsic too.

The really clever part about DPML's implementation is that it doesn't just construct one state bearing space. It actually uses the same approach to provide state to the execution of closures. If you think too hard about it you start to understand that during runtime, the DPML code explodes into a dynamic sea of state spaces.

Why the heck would you go to all this trouble? Well its just as we always say - when you make state extrinsic there's the opportunity that someone else can reuse it. What if you have an active:if request and its condition has not changed since the last time it was requested - the "true" representation can come straight out of cache...

There is no faster answer to a computational algorithm than not to compute at all.

Incidentally - DPML is a very easy to learn language - when you've learned the mapper - then DPML is just sequencing requests. But if you don't want to learn DPML you can always use nCoDE. Since nCoDE actually gets transrepted to DPML and runs on the DPML runtime!

Review: Samsung Galaxy S3

I've spent a lot of time away from home this year and countless days in the air. As a psychological "motivational reward" to myself I did, what for me, is a very rare thing. I became a first-in-the-queue, must-get-it-now consumer. I bought a Samsung Galaxy S3.

If you're a regular reader of these newsletters, you'll know I had been a steadfast late adoptor of smartphones. Not believing that they'd crossed the affordability/capability threshold until about this time last year.

I'm not going to bore you with another review of the "all singing all dancing iPhone killer" - you'll find plenty of those (here for example). No I thought I'd offer my perspective on the big picture...

Something just happened that is significant. The form-factor of this new generation of phones is now so large (4.8" screen) and with such a decent resolution (1280x720) that it no longer looks or feels like a phone. It looks like and feels like a computer. These are not smartphones, they are computerphones. Having a "phone peripheral" is just a convenient feature of this class of computer.

My prediction is that this form-factor has found its natural balance and is now here to stay. Any bigger and it would be unwieldy, any smaller and the usability is constrained by lack of screen real-estate (or just pixels that are unresolvable - retina-schmetima - its the Rayleigh critereon that matters).

So its got a quad-core processor - so far this has made no difference to me. So its got the latest Android - just as you'd expect, while this is technically version 4.0.x its actually the 3rd version of the android OS for cell phones. Its showing that "3rd generation polish" that you'd expect. Details work to the point that the OS disappears - as it should do.

I like the fact I can change the battery and plug-in an extra 64GB of flash (unbelievable - my phone has more solid state storage than my laptop).

I really don't like that by default there is no way to tell it to stay on all the time when its plugged into the power. Someone somewhere still thinks this is a phone! Its not - its sitting on my desktop next to my laptop display and its second monitor. Combined I am surrounded by a net 4 million pixels. The phone quite naturally becomes the messaging hub - while my other pixels are used to do real work (such as write rubbish like this). (In case you're interested this tool sorted out my "always on" requirement).

I'm sure that this phone is not the end of the evolution. But it does mark the end of the unstable exploratory technology spurt. The factors are now understood, the balance is struck. The competition from now on is in driving down costs, and on positioning a device in the 4 or 5 segments that will be the natural economic market. And of course, in the services and resources that live in the network (cloud *spit*) which these things are really just the physical footprint to...

...now where's my Android devkit again, its time to get NK up on this thing again...