Back

team.sPace Version 2.0 beta

For the winter school I made some improvements of the team.sPace. The key improvement is to have group support in the environment. Furthermore, I made team.sPace more responsive and removed the restriction of external caching of the feeds. With these improvements the entire system scales a bit better for bigger communities.

How does grouping works in team.sPace?

The most visible part of the grouping is the URL scheme extension. That is that the group name is part of the URL of the team.sPace of a group. That allows users easily to remember the URL of their community. Behind the scenes some more improvements had to be made, because all the layers in team space are implemented as independent services.

For the feed aggregation and caching I added a group-user matching. That means that users can get assigned to groups, and - more importantly - users can be part of several groups. In order to become a member of a group an authenticated user has to go to a group in team.sPace. The system will then recognise that the user wishes to become part of the group and automatically assigns the user to that group. For now this is not so much of a problem, as I have only two more or less independent groups with little overlap. In a future release I will add some front end functions so users can explicitly join groups, leave them, and create new groups.

One of the core ideas in grouping in team.sPace is related to the "learning networks" idea. That means that a user takes all contributions that have been cached so far, are automatically contributed to those groups which the user joins.

In order to facilitate grouping for contextualisation, I added two grouping sensors to the sensor layer. This allows to determine, if a users has been registered already to a group or not. Based on this information all aggregators are limited to the active group of the user. This means that the indicators change from group to group, depending on the activities of the other users.

Dynamic loading of resources

The second extension aims at the scalability of the feed caching procedure. Until this version team.sPace used an offline caching approach. This lead to the the unsatisfying situation that user contributions did not become available as soon as the user makes them available, but with a time delay.

With the current version of team.sPace I replaced the mechanism with a Net::Tube based feed processing. This way the Net::Tube takes care of loading and caching the news feeds and social bookmarks of the team.sPace users. I added a special filter that is capable of analysing and caching the incoming feeds within team.sPace. This feed caching is no longer run independently from the web-site's requests but became an integral part of the web-service. I.e. with every request team.sPace checks now if some participant's feed has changed and if it has done so, it loads the new data into the team.sPace cache.

This approach has also its draw backs, which I already approached in the new team.sPace TubeLoader.

  1. If the cache of all feeds expires around the same time, the first user that requests the web-site will experience a huge lag before the web-site loads.
  2. If all feeds are requsted around the same time, some feed generators such as del.icio.us will put a penality on the requesting service, and refuse to reserve the request from that service for some time.

I approached the first problem by settin varying cache life spans to the different feeds, so the feeds expire randomly from between 30 minutes to 180 minutes in 15 minutes steps. This dynamic cache life span will cause that only some feeds are loaded with each request as it is unlikely that all chaches expire around the same time. This dynamic assignment of cache life spans approaches also the second problem, because that way only a few feeds are loaded from generator services at a time.