Differences

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

--- research:doforreal [2010/08/04 12:29] – small stijnm
+++ research:doforreal [2010/08/04 13:34] – Note stijnm
@@ Line 1: / Line 1: @@
 ====== Distributed Objects for Real ======
-In the past few years, researchers at the Software Languages Lab have performed a number of experiments to discover how to facilitate the development of so-called __Mo__bile
+Over the past year, a number of researchers at the Software Languages Lab have been involved in experiments designed to uncover new programming abstractions to facilitate the development of mobile RFID-enabled applications.  During these experiments, we have approached the development of such applications from two opposing perspectives, which are briefly described below.
-__R__FID-__ena__bled (Morena) applications.
-Over the past year, we have developed two opposing programming models to represent RFID tags in an application.  Both cater to different kinds of Morena applications, as we shall illustrate below.
 == Volatile Data Clouds ==
+<note>The volatile data clouds model can be considered a special case of [[research:recap]] specifically applied to the domain of mobile RFID-enabled applications.</note>
 The //volatile data clouds// model considers RFID tags to be data containers whose presence or absence can be used to steer the application.  Therefore, it focusses on designing a general means to represent the collection of currently visible tags.
@@ Line 12: / Line 10: @@
 Since the collection is implicitly tied to the environment and changes frequently in response to events emitted by the RFID reader, //change// is at the very heart of the model.  To permit application developers to respond to and propagate these changes without having to explicitly register a plethora of observers, we borrow concepts from [[research:rp|reactive programming]].
-When programing with reactive values that represent the collection of visible tags, the programming language needs to provide the following support.  First of all, support is needed for //reactive collections//, such that operations such as ''size'' and ''contains'' result in a reactive value that changes when the collection changes.  This necessitates the introduction of reactive programming support in the programming language.  Reactive programming has been successfully incorporated in various languages including Scheme, Java.
+Concretely, the collection of visible tags is modeled as a //reactive collection//. In order to test for the presence of a particular tag, one can invoke the ''contains'' method of the reactive collection, which results in a new dependent reactive value.  That value is transparently updated whenever the collection changes.  This automatic propagation of changes to a reactive collection of RFID tags is a determining factor in the expressiveness of applications that use the volatile data cloud metaphor.
-Furthermore, such collections should provide //memoized iteration// constructs (e.g. ''map:'').  Hence, when mapping a function //f// over a source collection //s//, a memoized ''map:'' produces a derived collection //d// by simply mapping //f// over the current elements of //s//.  If at any later point in time, a new element //a// is added to //s//, the update will not cause the derived collection to be computed anew.  Instead, //d// is extended with a single new element, to wit //f(a)//.  Similarly, when an element //r// is removed, only the value //f(r)// is removed from //d//.
+Another important aspect is efficiently detecting when interesting patterns occur in a reactive tag collection.  A pattern of interest can be the presence of a particular (kind of) tag, but should extend to combinations of interesting tags.  To detect such
+occurrences, we make use of [[research:patterns|pattern matching rules]] which can be applied to any reactive collection.  This technique allows building RFID applications using a declarative programming style.
-Most importantly, the programming language should provide support to detect interesting patterns as they occur in a reactive collection.  A pattern of interest can be the presence of a particular (kind of) tag, but should extend to combinations of interesting tags.  Therefore, we propose a model which uses //pattern matching rules// to detect changes of interest in the application's environment.  An application could for instance specify a rule which triggers when the tags that represent the user's keys and coat are detected simultaneously.  Such a rule could be used to remember that the user is likely to have left his keys in one of the pockets of his coat.
+== Tags Objects ==
-== Tags Objects ==
+<note>
+The tag objects model represents RFID tags as full-blown objects, which introduces a natural mechanism to deal with **mutable tag data**.  More information as well as videos of our experiments can be found on a [[research:rfid|dedicated page]].
+</note>
 While the //volatile data clouds// model considers RFID tags as containers of data which is to be filtered and interpreted by the application, the //tag objects// model interprets them to be full-blown objects.  Applications can interact with these objects and e.g. invoke methods on them.  In this case, the tag contains a marshalled object representation which is implicitly unmarshalled to provide a live object which applications can interact with.