uf:proximities
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
uf:proximities [2008/09/05 11:28] – added tvcutsem | uf:proximities [2009/11/18 13:51] – updating elisag | ||
---|---|---|---|
Line 11: | Line 11: | ||
Proximities translate these events into addUser / removeUser events to be processed by flocks. To process these events, flocks register themselves on their dependent proximity. | Proximities translate these events into addUser / removeUser events to be processed by flocks. To process these events, flocks register themselves on their dependent proximity. | ||
- | As a first implementation of the RETE-network, | + | ===== Example ===== |
+ | Programmers can make customised proximity functions. In order to aid the programmer in this tasks we have defined some auxiliary functions and constructors. In the code shown bellow we make a proximity function that maps the domain of persons onto the set of people who are both female and friends in the proximity. The first step in the code is to create the female proximity. This is constructed by making a profile proximity. The first parameter is the flockr and the second is a lambda which expects a profile. This lambda must return a boolean value and indicates that the matched profile is in the proximity or not. In this case we check that the sex of the profile is female. The second proximity is a predefined one and only passes friends that are in the neighbourhood. The last step is to combine the two defined proximity' | ||
+ | |||
+ | |||
+ | < | ||
+ | def femaleProximity := makeDoesProfileMatchProximity(flockr1 , { |profile| profile.sex == " | ||
+ | def friendProximity := makeIsFriendProximity(flockr1); | ||
+ | def friendAndFemaleProximity := makeAndProximity(femaleProximity, | ||
+ | </ | ||
+ | |||
+ | ===== Implementation ===== | ||
+ | |||
+ | An ad hoc RETE-network. Events are triggered by: | ||
+ | * discovery: '' | ||
+ | * profile changes: '' | ||
+ | * friend changes: '' | ||
+ | |||
+ | These events are received by the local flockr user object and propagated to all local proximities. Proximities translate these events into addUser / removeUser events to be processed by flocks. To process these events, flocks register themselves on their dependent proximity. | ||
+ | |||
+ | [[: | ||
+ | |||
+ | |||
+ | Alternative | ||
< | < | ||
Line 27: | Line 49: | ||
Note of Tom: maybe too complex to use the templates, because we are not going to match on type tags or methods (only on state). We can simply compile proximities into boolean expressions of the form (ATTR OP VAL) | Note of Tom: maybe too complex to use the templates, because we are not going to match on type tags or methods (only on state). We can simply compile proximities into boolean expressions of the form (ATTR OP VAL) | ||
+ | |||
+ | ===== Open Issues ===== | ||
It appears that some proximities are mandatory, e.g. a composite proximity requires at least the isFriend / isNearby / wasNearby proximity functions. The doesProfileMatch proximty is optional. So we have the following constraints on proximities: | It appears that some proximities are mandatory, e.g. a composite proximity requires at least the isFriend / isNearby / wasNearby proximity functions. The doesProfileMatch proximty is optional. So we have the following constraints on proximities: | ||
Line 34: | Line 58: | ||
* there must be at least one of isFriend / isNearby / wasNearby | * there must be at least one of isFriend / isNearby / wasNearby | ||
* there can be 0 or more doesProfileMatch proximities | * there can be 0 or more doesProfileMatch proximities | ||
+ |
uf/proximities.txt · Last modified: 2009/11/30 16:42 by dharnie