Kosik: I am open to discussing the text (see the note in Talk:Ambient_capability page). Until then, it was deleted because it makes little or no sense.

Kosik — Mon, 13 Jul 2009 12:00:03 GMT

I am open to discussing the text (see the note in Talk:Ambient_capability page). Until then, it was deleted because it makes little or no sense.

New page

Dmbarbour at 22:12, 9 July 2009

Dmbarbour — Thu, 09 Jul 2009 22:12:13 GMT

←Older revision	Revision as of 22:12, 9 July 2009
Line 1:	Line 1:
	+	Ambient capability describes constraint and provision of operations by virtue of [[context]]. The term is very useful in discussion of distribution and mobility of code and service components.

	+	== Application ==
	+
	+	Ambient capability is applicable for many reasons. A few are:
	+	* limitation of [[namespace\|namespaces]]: namespaces are artificial constructs, and both [[secure naming]] and [[designation]] can occur only performed under the umbrella of an [[ambient authority]]. A designation querying a "keyboard" may have different meaning (i.e. applying to different physical keyboards) given different contexts.
	+	* limitations on [[communication]]: even if a namespace is properly maintained, there inherently exist limitations over communications. Networks may be partitioned, connections disrupted. Temporal windows for send and receive might fail to match.
	+	* [[primitive capability\|primitive capabilities]]: any programming language will offer a set of ambient capabilities via its interpreter. Use of console IO, access to filesystem, ability to ask for the current time or a random number, consumption of CPU resources and memory, communications support, etc. are often ambient and ''usually'' offer [[excess authority]] in order to achieve some degree of flexibility.
	+	* capabilities to ambient resources: at the edges of a useful programming language, one must interact with sensors and actuators. These objects are provided by an 'operating system' of some sort that will abstract devices in terms of data-flows, event-flows, and objects subject to command. To said operating system, the capabilities being accessed are inherently ambient.
	+
	+	On the last point, some security and optimization strategies are achieved by layering languages with different levels of ambient capability in each language layer both in order to avoid [[excess authority]] and support more optimization assumptions.
	+
	+	As with [[ambient authority]], it is HOW operations are constrained or provided that determines whether one is discussing an 'ambient' capability. However, one can very reasonably argue that ALL capabilities are, to some degree, 'ambient'. While this introduces some fuzziness, the term [[ambient capability]] can be utilized effectively when the ambient nature of a capability is very significant to achievement of engineering properties - such as distribution and mobility of code.
	+
	+	[[Object-capability languages]] aim to minimize the role of [[ambient capability]] in order to achieve certain forms of security.
	+
	+	== Relation to Ambient Authority ==
	+
	+	[[Ambient authority]] will '''allow''' or '''deny''' operations in accordance with a set of '''permissions''' that are provided within a [[context]]. A denial of an operation due to permissions is merely one mechanism by which ambient capability may be constrained.
	+
	+	However, allowance for an operation does not support or provide for that operation. You may easily be ''permitted'' to perform and command operations that you ''cannot'' perform due to [[context]].
	+
	+	Thus, [[ambient authority]] can be considered a ''limitation'' on [[ambient capability]].

Ambient capability - Revision history

Kosik: I am open to discussing the text (see the note in Talk:Ambient_capability page). Until then, it was deleted because it makes little or no sense.

Dmbarbour at 22:12, 9 July 2009