Differences

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

--- research:doforreal [2010/08/04 14:36] – Minor stijnm
+++ research:doforreal [2010/08/04 17:34] (current) – shortened tvcutsem
@@ Line 1: / Line 1: @@
 ====== Distributed Objects for Real ======
-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.
+Over the past year, the Software Languages Lab has been experimenting with new programming language abstractions for mobile RFID-enabled applications. We approached the development of such applications from two opposing perspectives, each outlined below.
-During these experiments, we have approached the development of such applications from two opposing perspectives, which are briefly described below.
 ===== Volatile Data Clouds =====
@@ Line 17: / Line 15: @@
 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.
-===== Tags Objects =====
+===== Proxy 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 [[research:rfid|here]].
+The proxy objects model represents RFID-tagged physical objects as full-blown software objects, which introduces a natural mechanism to deal with **mutable tag data**.  More information as well as videos of our experiments can be found [[research:rfid|here]].
 </note>
-While the //volatile data clouds// model considers RFID tags to be containers of data which is to be filtered and interpreted by the application, the //tag objects// model conceived them as hosts for full-fledged objects, which encapsulate mutable state and provide their own methods.
+While the //volatile data clouds// model considers RFID tags to be containers of data which is to be filtered and interpreted by the application, the //proxy objects// model conceived them as hosts for full-fledged objects, which encapsulate mutable state and provide their own methods.
-When interacting with these tag objects, one has to deal with the ephemeral nature of the connection between the mobile RFID-enabled application and any particular tag.  The concerns to be addressed when interacting with tag objects closely mimic those that govern
+When interacting with these proxy objects, one has to deal with the ephemeral nature of the connection between the mobile RFID-enabled application and any particular tag denoted by a proxy object.  The concerns to be addressed when interacting with RFID-tagged physical objects closely mimic those that govern
 the interaction with classic remote objects:
-First of all, mobile RFID-enabled applications need a means to detect when a particular RFID tag has come into range.  As RFID tags are modeled as devices hosting an object, the most natural
+First of all, mobile RFID-enabled applications need a means to detect when a particular tagged object has come into range.  As RFID tags are modeled as devices hosting an object, the most natural
 mechanism to achieve this is to use the default [[at:tutorial:distribution#exporting_and_discovering_objects|service discovery mechanisms]] of AmbientTalk.
-Once a tag object has been discovered, the application can start to interact with it.  However, if either the user of the application or the tagged object is roaming, it is extremely likely that the tag will (temporarily) go out of range.  Hence,  application programmers are provided with [[at:tutorial:actors#ambienttalk_actors_and_far_references|far references]] to the tag objects.  This design ensures that tag objects can only be addressed using asynchronous messages and it implies that when a tag goes out of range, all messages that are sent to it are [[at:tutorial:distribution#dealing_with_transient_failures|buffered]].  Subsequently, when the tag comes in range again, these buffered messages will be flushed and forwarded to the tag.
+Once a proxy object has been discovered, the application can start to interact with it.  However, if either the user of the application or the tagged object is roaming, it is extremely likely that the tag will (temporarily) go out of range.  Hence,  application programmers are provided with [[at:tutorial:actors#ambienttalk_actors_and_far_references|far references]] to the proxy objects.  This design ensures that proxy objects can only be addressed using asynchronous messages and it implies that when a tag goes out of range, all messages that are sent to it are [[at:tutorial:distribution#dealing_with_transient_failures|buffered]].  Subsequently, when the object comes in range again, these buffered messages will be flushed and forwarded to the tag on the object.
-By aligning tag objects with remote objects, one can develop mobile RFID-enabled applications without having to learn about a new concept.  Furthermore, application programmers can rely on the entire arsenal of abstractions to deal with remote objects. For instance, one can be notified of disconnection using the default //disconnection// and //reconnection listeners//.
+By aligning tagged objects with remote objects, one can develop mobile RFID-enabled applications without having to learn about a new concept.  Furthermore, application programmers can rely on the entire arsenal of abstractions to deal with remote objects. For instance, one can be notified of disconnection using the default //disconnection// and //reconnection listeners//.
-A particularly interesting abstraction when developing mobile RFID-enabled applications are [[research:ambientrefs|ambient references]].  First of all, such references introduce mechanisms to clearly specify which objects one wants to refer to (i.e. one can impose additional constraints beyond the type of the object).  Additionally, ambient references provide a mechanism to implicitly denote and send messages to a collection of (tag) objects.
+A particularly interesting abstraction when developing mobile RFID-enabled applications are [[research:ambientrefs|ambient references]].  First of all, such references introduce mechanisms to clearly specify which objects one wants to refer to (i.e. one can impose additional constraints beyond the type of the object).  Additionally, ambient references provide a mechanism to implicitly denote and send messages to a collection of (proxy) objects.
 ===== Comparison =====