Re: history

[Rudolph P. <r.p...@is...>]

On Tue, Sep 16, 2003 at 09:20:54PM +0100, Will Partain wrote:
> Rudolph Pereira asks:
> 
> > I'm wondering whether anyone has, or knows how to implement or have
> > history in ark/arusha.
> 
> As far as I'm aware, not much has been done.  The main
> reason I guess is that, while there are Twenty Cool Things
> one can think of, no compelling need has arisen (at least
> for me) that would put me in front of a keyboard for a week.
> 
> What we *do* do: Methods can be marked 'recordable' (and
> lots are).  When they run, they record a few things about
> themselves (who, when, what code, where parameter settings
> came from...) in the "state directory".  This info is mainly
> used to avoid re-doing such methods, but I have also been
> known to go rooting around in there to see what happened N
> months ago...
> 
> A few further developments of the "state directory" would (I
> suspect) be not much work:
> 
> * Write some scripts to walk over the state info (it's all
>   supposed to be well-formed XML), and tidy up any mess that
>   is inadvertently there.
> 
>   An example script might be to find all the methods that
>   used old versions of tools (e.g. an old GCC) and set up
>   something for re-running them (with the new versions).
> 
> * Add to the state dir/stuff the stdout/stderr outputs from
>   running the methods' code.  I do sometimes wish I could
>   answer "Now, what the heck did 'make' do when I built
>   libtiff on solaris8 back in March?"
> 
> * As you suggest, record the full (static) state of the
>   object at time of a method invocation.  (In theory, this
>   could be reconstructed just from CVS info.)
> 
> I would be interested in what you see as a compelling use
> for "history" as you envision it.  ???
To put it as generally as possible, it would be nice to have the state
appearing as part of the object, and not just stored on the machine
itself. All of the recordable stuff you mention seems like a good
candidate for my idea of state.

Stepping further back, I am considering a pull rather than push
architecture in which ark may/will be used. In that situation, one may
make changes to an object/method (well, it's source). A machine may then
pull down and act on those changes some time in the future. Recording
the actual (versus the intended) state of an object on a machine, and
what it did to (try to) get from intended -> actual (at a particular
time), possibly including the stdout/err output you mention, would be a
good thing.