Ambient-Oriented Programming

User Tools

Site Tools

Trace:
research:recap

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision 		Previous revision
research:recap [2010/07/31 14:54]
stijnm created 		research:recap [2010/07/31 18:23] (current)
stijnm added
Line 2: Line 2:
 ===== Reactive Context-Aware Programming ===== ===== Reactive Context-Aware Programming =====
 [[http://soft.vub.ac.be/soft/members/stijnmostinckx|Stijn Mostinckx]] [[http://soft.vub.ac.be/soft/members/stijnmostinckx|Stijn Mostinckx]]
- 
-<note> 
-This page is under construction, some sections are not yet completed. Please refer to the [[:research:rfid#further_reading|further reading]] section for a full text. 
-</note> 
  
 Reactive Context-Aware Programming (ReCAP) extends the ambient-oriented programming paradigm to tailor it for the Internet of Things (IoT): a network environment in which physical objects are given an embedded digital representation.   Reactive Context-Aware Programming (ReCAP) extends the ambient-oriented programming paradigm to tailor it for the Internet of Things (IoT): a network environment in which physical objects are given an embedded digital representation.  
Line 12: Line 8:
  
 ==== Causally Connected Applications ==== ==== Causally Connected Applications ====
 +† Quick-link: [[research:rp|Reactive programming]]
  
 +IoT applications are //causally connected// to their environment; the presence, proximity and current state of nearby devices and physical objects is used to customize the services and information offered by the application.
  
 +Reacting to changes in the environment requires registering one or more event handlers.  For instance, if an AmbientTalk application wants to respond to the appearance and disappearance of nearby devices, it has to register ''whenever:discovered'' and ''whenever:disconnected'' event handlers.  
 +
 +The use of such event handlers introduces an //inversion of control//, where the control flow of the application is scattered across a number of event handlers.  This inversion of control is particularly jarring if the application logic demands the use of
 +additional event handlers to propagate environmental changes to modules which are only indirectly affected by them.  
 +
 +Note that it is often possible to avoid the inversion of control altogether.  For instance, to abstract over (dis)appearing communication partners, one can use an [[research:ambientrefs|ambient reference]]. In the general case, the inversion of control can often be removed through the use of [[research:rp|reactive values]].
  
 ==== Window on the World ==== ==== Window on the World ====
 +† Quick-link: [[research:patterns|Pattern matching]]
 +
 +One of the key elements of the IoT is that all physical objects are equipped with an embedded digital representation (e.g. using an RFID tag). Given the premise that the presence of any given  object can be a cue that steers the application of IoT applications, it is crucial that programmers have adequate tools to describe the applications //window on the world//.
 +
 +The window on the world denotes the set of physical objects and devices whose presence or absence has to be reported to the application.  Determining whether an object is visible in an application's window on the world may depend on its type, current state, as well as on the presence or absence of other objects.
 +
 +In the ReCAP paradigm, the window of the world is constructed using [[research:patterns|pattern matching]] rules, which are applied to a [[research:rp|reactive]] representation of the application's context.  
research/recap.1280580840.txt.gz · Last modified: 2010/07/31 17:08 (external edit)

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki