mission critical apps

Richard Gaskin ambassador at fourthworld.com
Mon Feb 9 20:05:34 EST 2004


Alex Rice wrote:

>> What specifically is needed, and what are the challenges of building
>> it?
...
> Brian:
> Developers that use CVS, Subversion etc. often use it on solo projects
> as well! It's very empowering to be able to "turn back the clock" on
> all or part of your code. IBM Visual Age for Java which has a
> "repository" where project code could be freeze-dried, versioned, and
> saved for later use or inspection. Good stuff, even working solo.

Brian's never seen Chipp's versioning auto-saver?

> Richard:
> If there were a version-control plugin for runrevI would surely be a
> customer! I believe some ideas have been kicked around on-list for
> mapping Rev stacks into a version control system. Some hurdles one
> would be looking at are:
> 
> - lack of specific hooks in IDE for controlling the script editor, the
> application browser, and property inspector.

What can't be hooked ? It's all exposed.  It can be useful to automate code
changes so you can maintain an updater utility to run those after
downloading a fresh Rev.  I used to do some of this in a utility called
"FixMC" which wormed its way through portions of the IDE to touch up some
appearance and behavior issues.

Once you've idntified the specific hooks you need and how they should work I
imagine RunRev would jump at the chance to put those hooks directly in the
product.

> - background groups - are they placed or not placed? How many cards are
> they placed on? I found trying to envision a stack as a filesystem
> hierarchy then background groups get confusing.

Then find another mental model. :)

Seriously, this comes up in HyperRESEARCH all the time. Some concepts defy
tradtional hierachies.

But shared backgrounds are useful objects, so there must be some way to map
it into a database and it seem worth doing.


> - proprietary binary stack format - depending on perspective it may be
> a non-issue because we need to have version control from within the IDE
> not from the filesystem.

Proprieary schmoprietary. :)  Everything can be atomized, disassembled,
reassembled at will.  Design how you want it to work and there are plenty of
people who can help figure out the implementation.

Running in the IDE yes, but it needn't reside in the IDE stackfiles. It
could be done as a plugin.

The IDE is exposed, so in the rare cases where you might want to modify it
you could.  But you could probably do all you need from a plugin with just
backscripts and frontscripts without requiring direct modification.

Then again, if you come up with a good system that could be even better if
more deeply integrated in the IDE I can't imagine the folks at RunRev
turning you down.

My point is that it's all quite doable.  It should be possible to come up
with a useful collaborative system for general development in less time than
you'd save working with it.

A number of others here have expressed a similar interest. If an open source
team was established to create such a system it may attract all the
resources needed to do a good job and have fun doing it.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com



More information about the use-livecode mailing list