User Tools

Site Tools


uf:flockr

Differences

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

Link to this comparison view

Next revision
Previous revision
Last revision Both sides next revision
uf:flockr [2008/09/04 15:22]
elisag created
uf:flockr [2009/11/18 14:34]
elisag
Line 1: Line 1:
 ==== Flockr ==== ==== Flockr ====
  
-Each Flockr has :+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 :
   * [[Profile]]    * [[Profile]] 
-  * list of its [[Flock]]s where it is registered. +  * list of its [[Flock|flock]]s where it is registered.  
-  * list of its [[Flock]]s. +    * Note: maybe it should be stored in the profile
-  * list of its friends ([[Flockr]]s references) 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.+  * list of its [[Flock|flock]]s. 
 +    * predefined [[Flock|flock]]s ( e.g. buddyList). 
 +    * user-defined [[Flock|flock]]s
 +  * 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 has a local and remote interface. 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]]. 
 + 
 +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 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|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:  
 +    * Make "cached" object abstraction. It is just a proxy object which forwards to the online version when it's online, otherwise the catched version. Every update, replaces the cached version with a clone. In other words, keeps a cached object that gets updated when you are connected. 
 +    * This abstraction could be used for any list of Flockrs that need offline Profile visualization. Maybe useful also for applications. 
 + 
 +Other Comments: 
 + 
 +[[Flockr]] actually should be able to decide who can see him. How? maybe Profile?
  
 +===== API =====
  
-==== API ====+  * Local Interface 
 +    <code>  
 +    registerProximity(proximityObj) 
 +    friendAdded(uid,flockr)    
 +    friendRemoved(uid,flockr) 
 +    </code>
  
 +  * Remote Interface
 +    <code> 
 +    joined(uid,flockr) 
 +    left(uid,flockr) 
 +    changedProfile(uid,flockr,updatedProfile)
 +    getProfile() 
 +    </code>
uf/flockr.txt · Last modified: 2009/11/30 16:49 by dharnie