Changes

Jump to navigation Jump to search
m
Line 1: Line 1: −
{{Sugar Almanac}}
+
{{Almanac}}
 
=== How do I setup a D-Bus Tube? ===
 
=== How do I setup a D-Bus Tube? ===
   −
Let's first look at what conceptually happens to make activity sharing work. The diagram below shows two instances of the same activity: the "Sharing Activity" and the "Joining Activity". The sharing activity is the activity that is initially run and shared with other buddies. The "Joining Activity" refers to other instances of the activity that are created once buddies decide to join an activity that has been shared. You can allow an activity to be shared (making it a sharing activity) by  [[Sugar.presence.presenceservice#How do I share an activity with other buddies in my neighborhood? | including the standard Sugar Activity Toolbar]].
+
Let's first look at what conceptually happens to make activity sharing work. The diagram below shows two instances of the same activity: the "Sharing Activity" and the "Joining Activity". The sharing activity is the activity that is initially run and shared with other buddies. The "Joining Activity" refers to other instances of the activity that are created once buddies decide to join an activity that has been shared. You can allow an activity to be shared (making it a sharing activity) by  [[Development Team/Almanac/Sugar.presence.presenceservice#How do I share an activity with other buddies in my neighborhood? | including the standard Sugar Activity Toolbar]].
    
[[Image:tube-setup.jpg | How Tubes are Setup]]
 
[[Image:tube-setup.jpg | How Tubes are Setup]]
Line 110: Line 110:  
     def _new_tube_cb(self, id, initiator, type, service, params, state):
 
     def _new_tube_cb(self, id, initiator, type, service, params, state):
 
          
 
          
         if (type == telepathy.TUBE_TYPE_DBUS and service == SERVICE):
+
         if type == telepathy.TUBE_TYPE_DBUS and service == SERVICE:
 
             if state == telepathy.TUBE_STATE_LOCAL_PENDING:
 
             if state == telepathy.TUBE_STATE_LOCAL_PENDING:
 
                 #Accept the new tube that has been created  
 
                 #Accept the new tube that has been created  
Line 476: Line 476:  
         assert isinstance(addr[0], str)
 
         assert isinstance(addr[0], str)
 
         assert isinstance(addr[1], (int, long))
 
         assert isinstance(addr[1], (int, long))
         assert addr[1] > 0 and addr[1] < 65536
+
         assert 0 < addr[1] < 65536
 
         port = int(addr[1])
 
         port = int(addr[1])
   Line 495: Line 495:     
=== Where do I get more information regarding sugar activity sharing and the technologies that support it? ===
 
=== Where do I get more information regarding sugar activity sharing and the technologies that support it? ===
* A [[Shared_Sugar_Activities | brief tutorial]] on activity sharing for the OLPC laptop.
+
* A [[Development Team/Almanac/Shared_Sugar_Activities | brief tutorial]] on activity sharing for the OLPC laptop.
    
=== I can't get tubes to work.  Are there unresolved issues? ===
 
=== I can't get tubes to work.  Are there unresolved issues? ===
 +
 +
==== Which threading patterns are most appropriate for use on the sugar platform? ====
 +
 +
<p>
 +
There are issues regarding the best way to create activities that support media sharing. In particular, the structure of DBus tubes makes it easy to customize the communication process between activity instances running on multiple XOs. However, stream tubes seem to be tied closely to a client server architecture - the servers and handlers provided in sugar.network package are some form of client/server arrangement.
 +
</p>
 +
 +
<p>
 +
Setting up more advanced stream tubes functionality that would allow sharing of non-text data (eg. binary files, images, etc.) in a continuous manner in the way dbus tubes enable text communication is complicated.  To allow activities to communicate constantly over a stream tube, one needs to set up both a client and server side on each activity and coordinate communication between them. Furthermore, most activities would require threading as well, which means resolving best practices for threading. Ultimately, it seems that the existing servers/handlers to support stream tubes may not be adequate to support easy and relatively painless sharing of data between activities on a continuous basis. The code that is on the Almanac right now guides a user through the basic process of setting up a stream tube and allowing communication one time between the server and client. This is useful for sharing/joining activities that require sending binary files (which is why Record and Read use this). However, it does not extend easily to peer to peer communication.
 +
</p>
 +
 +
<p>
 +
One solution to sending non-text data between activities is to just use the DBus tube and take advantage of its flexibility. It's not clear how well these tubes will support binary data, however and whether they work well with larger media files. It would be helpful to get insight from sugar developers regarding how such communication should work and what facilities sugar needs to add to support this (perhaps more functionality for stream tubes in sugar.network). Given that peer to peer networking through mesh is probably one of the standout features of XO laptops, I think having better functionality (and better documentation) for developers to build rich communicative applications is a high priority.
 +
</p>

Navigation menu