User Tools

Site Tools


uf:flockr

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
uf:flockr [2008/09/05 11:47]
elisag
uf:flockr [2009/11/30 16:49] (current)
dharnie *correct
Line 1: Line 1:
 ==== Flockr ==== ==== Flockr ====
 +
 +A flockr represents a user in the framework. A flockr has exactly one profile and can create and be registered to multiple flocks. In addition, a flockr can have multiple installed applications. A flockr is also the gateway that remote parties can use to get information about the user.
  
 Each Flockr contains following info : Each Flockr contains following info :
-  * [[Profile]]  +  * [[profiles|Profile]]  
-  * list of its [[Flock]]s where it is registered. +  * list of its [[Flock|flock]]s where it is registered. 
     * Note: maybe it should be stored in the profile.     * Note: maybe it should be stored in the profile.
-  * list of its [[Flock]]s. +  * list of its [[Flock|flock]]s. 
-    * predefined [[Flock]]s ( e.g. buddyList). +    * predefined [[Flock|flock]]s ( e.g. buddyList). 
-    * user-defined [[Flock]]s.+    * user-defined [[Flock|flock]]s.
   * list of [[Proximities]] that are registered for this Flockr.   * list of [[Proximities]] that are registered for this Flockr.
 +  * list of its [[Application|applications]].
 +  * a map of usernames to far refs to connected flockrs.
  
-A Flockr will have a local and remote interface.  +A Flockr has a local and remote interface. The remote interface is the entity that gets exported to the ambient. 
-The remote interface is the entity that gets exported to the ambient. +
  
-Profile won't get exported to the ambient but it has to proactively asked to the Flockr. This allows: 1) Remote Flockr does not need to ask the [[Profile]] again (if you rediscover the Flockr) if it didn't change and 2) allow the Flockr to decide who can actually see its [[Profile]].+Profile won't get exported to the ambient but it has to proactively asked to the Flockr. This allows: 1) Remote Flockr does not need to ask the [[profiles|Profile]] again (if you rediscover the Flockr) if it didn't change and 2) allow the Flockr to decide who can actually see its [[profiles|Profile]].
  
 The remote interface receives 3 types events from the network (join, left and changeProfile) and notifies the local interface of the Flockr which notifies the necessary [[Proximities]] objects.   The remote interface receives 3 types events from the network (join, left and changeProfile) and notifies the local interface of the Flockr which notifies the necessary [[Proximities]] objects.  
Line 19: Line 22:
 The local interface contains also receives the events on changes on the buddyList. The local interface contains also receives the events on changes on the buddyList.
  
-The buddyList is a list of its friends Flockrs. The editor for [[Flock]]s will allow that the [[Profile]] can be consulted offline. When a Flockr is connected for which there is a cached [[Profile]], he should propagate the necessary changed events to make sure that both the cached Profile and the Flocks of the other Flockrs are updated.+The buddyList is a list of its friends Flockrs. The editor for [[Flock|flock]]s will allow that the [[profiles|Profile]] can be consulted offline. When a Flockr is connected for which there is a cached [[profiles|Profile]], he should propagate the necessary changed events to make sure that both the cached Profile and the Flocks of the other Flockrs are updated.
  
   * xtof suggestion to implement this:    * xtof suggestion to implement this: 
Line 33: Line 36:
   * Local Interface   * Local Interface
     <code>      <code> 
-    registerProximity()+    registerProximity(proximityObj)
     friendAdded(uid,flockr)        friendAdded(uid,flockr)   
     friendRemoved(uid,flockr)     friendRemoved(uid,flockr)
uf/flockr.1220608072.txt.gz · Last modified: 2008/09/05 11:51 (external edit)