Active URIs

Home > Books > Tutorials and Training Guides > Getting Started > Active URIs

Introduction to Active URI

The World-Wide-Web is linked by URIs. To-date URI addressing has been quite closely associated with identifying the resources in file systems on servers - for example, think of an Apache web server directory. But nothing says that a URI has to be a static resource identifier....

What if we think about the URI as a vector through a resource address space? What if some of those resources are executable code? What if the URI expressed a program which calls that code?

URI as Functional Program

An Active URI is a functional program. The active URI locates a resource which is explicitly computed by the application of a function to a set of named resources. Each named resources is itself located by a URI. An active URI has the following form:

{scheme}:{type}+{arg}@{value}+{arg}@{value}+....

Where {scheme} is a valid URI scheme (often, active: or ffcpl:). {type} is an application specific type declaration which may itself be an escaped URI. {arg} is an argument name. {value} is an inner URI which is escaped.

Example

Here is an example: Suppose we have a function called active:toUpper, which transforms lowercase text to uppercase. This function expects a named argument called 'operand' which is the URI of the resource to be converted. Consider the following URI:

this URI explicitly describes the upper-cased form of the file somefile.txt. Try editing the operand's file: URI to point to a text file on your local filesystem. Now, since the 'operand' argument is just a URI then consider...


		
		
		This active URI performs the uppercase transformation of a text file hosted on a web-server (if you think this must be a fix ;-)
		try going directly to: http://www.1060.org/upload/toUpperDemo.txt).
		As you can see, any resource which can be located by URI can be processed within an active URI program.
		
		Nesting
		
		The Active URI is 100% compatible with the IETF [RFC2396,RFC1738] URI specifications and so can be used everywhere
		a URI can be used.
		
		
		Since a named argument is an escaped URI - it could therefore be another nested active URI.  So, by nesting Active URIs
		to arbitrary depth, the active URI expresses a multi-step program.  NetKernel resolves URIs to source resources. By lazily
		evaluating an Active URI, NetKernel performs a sequence of functional operations in the URI address space.
		
		
		Don't Panic! - deeply nested Active URIs are not for humans!  You should think of active URIs as NetKernel's assembly language.
		Its job is to evaluate active URI programs but a developer does not have to code in the active URI domain.  NetKernel
		provides APIs and declarative languages whose purpose is to abstract the elegant - but inhumane - simplicity of active URIs!
		
		Using Active URIs to address Accessors
		
		An Accessor is a NetKernel software component which embodies some executable code. 
		Accessors publish their interface in a module's URI address space as an active URI.  An accessor's active URI is a function or service
		which may be called from a program.  Often an accessor takes one or more named arguments identifying resources upon which it will operate.
		
		
		The convention for invoking an accessor is to use the active: scheme.
		
		
		The NetKernel distribution provides a large number of ready-made accessors for use in your applications.