i guess we'll see. obviously, you DON'T need time to represent change. in fact, the preferred mechanism is normally a state change in an FSM. time, because of its other properties, tends to confuse the issue (mostly by humans who bring a fair bit of baggage with it).
but the FSM story is another tale. On Nov 2, 2006, at 9:45 PM, Narayan Desai wrote:
Well, the actual point that we make in the paper is that you need an independent time variable in the configuration repository in order to be able to directly represent change. using an SCM repository revision was a convenient mechanism that also happened to be discrete. It was mainly convenient. Another reason we went this way is because the use of revision control is at least a familiar concept to users already; a separate implementation of this functionality would be pretty tough. It is also intertwined with auditing and understanding past states, so having all of the scm tools is nice. So I guess there are some factors that make it convenient, but that it doesn't need to be revision control based. You could make an implementation that uses a completely independent time variable, but it would probably be more unwieldy... -nld
---- Andrew Hume (best -> Telework) +1 732-886-1886 [EMAIL PROTECTED] (Work) +1 973-360-8651 AT&T Labs - Research; member of USENIX and LOPSA _______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
