I have had a fairly positive response to my last CAD Collaboration post. Feedback has highlighted a couple of areas that need clarifying and developing a little further.
On Snapshots and Deltas
Paul Wilkinson of the Extranet Evolution blog put up a fairly long post that discussed many aspects of the article. Of most interest was his comments on the snapshots and deltas idea, significantly the fact that a similar approach had been adopted three years ago by BIW Information Channel from BIW Technologies.BIW’s Accelerated Transfer pack condenses file revisions to a fraction of their previous size allowing faster transfer – up to ten times faster in the case of some files.
In the case of BIW it used delta encoding as a means of increasing data transfer speeds to remote, poorly connected places such as construction sites. This is slightly different to the concept I proposed because it deals with binary deltas rather than deltas at an abstracted digital model level. Binary deltas are great at a file level because they do allow changes to the same file be transferred somewhere very quickly. The problem is that binary deltas are intended to convert a file to a carbon copy of the remote source file from top to bottom.
Using delta's in a collaborative digital model is all about exchanging design intentions (i.e. rotated wall A 45 degrees) so that the model is updated but many properties of the actual file remain the same. In many respects it is more complex process than a low-level delta courtesy of a tool like diff. However this added complexity provides the benefit of enabling users to choose what design intentions they wish to inherit from other team members without worrying about the associated digital baggage that accompanies their team member's file.
Paul also raised this interesting point:
But what we need, as a commercial software developer, is some customer demand to make such R&D activity commercially viable - as with BIM, there is no huge clamour (yet) from project teams for collaboration tools to support this way of working.
Supply and demand is an interesting thing. Posing to a group of people whether they want to adopt a certain way of working without a having that method productised and easily accessible will always result in negative feedback. Twenty years ago I doubt researchers would have received a positive response if they asked architects to adapt their processes to meet the needs of a hypothesised 'Building Information Model'. The fact of the matter is that it has taken compelling yet somewhat risky tools like Archicad and Revit to convince industry professionals that a BIM approach has significant advantages over conventional CAD. This change of heart has not come about because professionals have come to terms with what the concept of BIM. Instead most have been sold on the idea because the products available have shown themselves to be more efficient and flexible than alternatives. I think a snapshots and deltas approach has significant advantages which I have previously described, but it will take the availability of a compelling product before the majority of users exhibit any degree of interest.
So how does a Satellite approach work again?
A link to the article was posted on the VectorWorks forum thread which was provided the initial spark. It received the following comment:It still remains a bit of a mystery to me how the "master/satellite" system is actually managed. I'm not aware that in writing to disk it is possible to write only selected portions of a file (I may be in error in this belief!).
In the updating process, does software on the server take master and satellite into one file, sort each object for permission and time stamp, then integrate into one file to overwrite the original?
At the heart of the satellite model is usually a permissions system that allows only one user to lock a selected area for editing. Other people are still able to view this area but for simplicities sake write privileges are usually kept to one person. Minimising write privileges negates the need to have a complex synchronisation process where one set changes are accepted or declined in place of another. It is certainly possible to write an application that deals with these issues of change authority but it is difficult to justify given its negative impact on application efficiency and ease of use.
Because of its simple permissions system synchronising a satellite is a simple task of overwriting the area assigned to the user within the master model with what is present in their satellite copy. Once this is complete the updated areas of the master not under the user's control are copied to the satellite. The process of updating the satellite can be as simple overwriting its entire contents with what exists in the master down to fine-grained synchronisation of new and updated elements.
It is perhaps easiest to think of the process like the children's game where each child is allowed to draw on a specific side of a folded-up piece of paper. The piece of paper is handed around each of the children in turn to draw on and after everyone has had a turn the unfolded end result is revealed (usually to much hilarity). The only significant process difference with a satellite approach is that instead of drawing on the same piece of paper copies are distributed for working on and collated into a master version at a set time.
Of course one thing to remember about a digital model is that its unique 'sides' do not have to be constrained by a physical space such as a kitchen. Instead these areas could be specific elements that occur throughout the model, for example 'all the windows on the second and third floors'.