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
Last revision Both sides next revision
uf:flockr [2008/09/05 11:46]
elisag
uf:flockr [2009/11/18 14:34]
elisag
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]]    * [[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 [[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]].
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 such 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 [[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.
  
   * 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.txt · Last modified: 2009/11/30 16:49 by dharnie