Ambient-Oriented Programming

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
• list of its flocks where it is registered.
  • Note: maybe it should be stored in the profile.
• list of its flocks.
  • predefined flocks ( e.g. buddyList).
  • user-defined flocks.
• list of Characteristic Function that are registered for this Flockr.
• list of its 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 Characteristic Function 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 flocks 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?

• Local Interface

 
    registerProximity(proximityObj)
    friendAdded(uid,flockr)   
    friendRemoved(uid,flockr)
    

• Remote Interface

 
    joined(uid,flockr) 
    left(uid,flockr) 
    changedProfile(uid,flockr,updatedProfile)
    getProfile()