3.5 The Watch Architecture Revisited
As the watch DSM environment was created purely as an example,
it is clear that in its current form it does not form a perfect vehicle for a
true real-life development project. The main problem comes from having to
support different operating systems for the build scripts. This necessitates a
property to select the build platform. Unfortunately, the property selection is
saved along with other properties, and thus would not work well in a multi-user
environment. As the property is changed by each user, on different platforms,
that property becomes locked and other users cannot change it — and hence
can only perform a build if they happen to be on the same platform.
A better solution, but one which would have been overkill
for this example as a single-user tutorial, would be to have another kind of
graph to specify build properties. The graph could consist of just properties,
for instance a name ‘Linux watch build’, the Generation target
platform selection ‘Linux’, and a property pointing to the previous
top-level graph, 2008Models. There could be a number of such graphs for
2008Models, one for Linux, one for Windows etc.
Another possibility, allowing still better multi-user
interaction, would be to make the build properties graph yet more generic by
adding a property containing the name of the generator to run, and making the
property data type of the graph reference be just Graph. This would allow each
user to make their own project with such ‘build command’ graphs for
a variety of uses.
Of course, the real situation in the organization should
be the deciding factor in designing such solutions. A little creative thought
about using generators, graphs and projects can often pay good dividends in
terms of smooth co-operative development.