The idea by example:
The idea can easily be extended to unify a cluster with an arbitrary RSS feed, allowing off-site web-logs to be unified with on-site clusters.
For example, you could even make a PeriPeri "announcements" cluster and syndicate that. Then you can make announcments about the PeriPeri project in one place yet have it syndicate to a bunch of places. In addition, as you were saying, you could have discussion spaces that existed on multiple wikis at once (the clusters). Great idea. -- BayleShanks
UnifiedClusters lets a community keep even more to one wiki. Instead of checking the RecentChanges pages of several sites, you only check one. If one person in the community finds an off-site cluster they feel is especially exciting and relevant, they can either make a new unified cluster for it, or combine it with one already on-site. -- ChrisPurcell
This is one of those cases where I'd just say the technology makes things more "fluid". It makes the boundaries between wikis hazier, it makes the boundaries between communities hazier, it makes the connection between a community of people and a wiki website hazier. This technology gives you more options in both directions: dissociating the community from the wiki, or keeping it in one space even more. -- BayleShanks
The basic mechanism used is probably RssInclusion. Thus, there should be a way to say which RSS feeds to use in a given cluster. In the above example, we want to specify on ExperimentalTechnology the RSS feed that gives us the changes to all pages in the PeriTechnology cluster on PeriPeri.
With a big difference in size between big A and small B, another similar feature starts to make sense: You can treat the entire small wiki B as as being in one cluster, and showing any change to B as a change to a cluster on RecentChanges of A. Presuming of course that moving B onto A and using PageClusters directly is architecturally/politically impossible. See WikiCanonicalization? for reasons you might want to split wikis into lots of small dedicated wikis.
This only makes sense if the community of wiki B is simply a subset of that on wiki A. As soon as there's any substantial community flow on wiki B (home pages, message boxes, et cetera), the "smallest unit of interest" is no longer the whole wiki. This holds even if that Wiki is otherwise entirely dedicated to a single interest cluster! A good example here would be PeriPeri, which is dedicated to the FacetWiki project, yet still has SandBox and HomePage activity. Fortunately, it's possible to make a scheme where treating a whole Wiki as a cluster is no harder than focussing on one of its clusters.
For both proposals above, notification and visualization problems have to be solved. The rest of this page discusses these problems and possible solutions.
Two scenarios are possible: Wiki B can push cluster changes to cooperating wikis, or wiki A can pull cluster changes from B. Pushing changes will make sure remote sites are always up-to-date; pulling changes may enable wikis to support remote cluster changes even for non-cooperating wikis (whether that be due to technical incompatibilities or social reasons).
Of course, not every cluster on wiki B will show up on wiki A's RecentChanges; just those clusters of likely interest to wiki A denizens, as chosen by said denizens.
A combination of push and pull is possible as well:
Note that this combination still allows a Wiki to pull changes from an uncooperative host, and a cooperative host can push changes without the subscribed Wiki knowing about it. Cooperative hosts get a maximum lag-time of ten minutes; uncooperative ones can be out of sync by an hour. -- ChrisPurcell
It is currently possible to use Oddmuse for the following scenario:
Create a page Y on A that shows the changes to cluster X on both wikis A and B. The RecentChanges on A will only show a change to cluster X when a page in the X cluster on wiki A is changed, however.
Define external redirect: WikiCanonicalization