Question on .rev file format

[Jan Schenkel]

--- Steve Gehlbach <steve at nexpath.com> wrote:
> Thanks to all who replied, your comments are very
> useful.
> 
> I guess I am not completely convinced that the
> pluses outweigh the 
> minuses regarding the Revolution binary format, but
> I will try to keep 
> an open mind.
> 
> Some other reasons for text formats:
> 
> - managing groups of engineers:  you can look at the
> nightly checkins to 
> CVS and see how many lines of code have changed. 
> Also can more easily 
> find when and by whom a bug was injected and how to
> fix it.
> 
> - CVS puts a version code in the text based on
> triggers like $Id$ etc, 
> which is very useful when managing various releases
> and finding which 
> version of code you have.  This would of course
> corrupt a .rev file.  I 
> have managed to get around this for many other tools
> (CAD programs, 
> document programs) since most have an optional text
> mode, such as .rtf 
> in Word.  But they also frequently have bugs so the
> binary format is 
> Truth, and the text mode is only close to the same. 
> .rtf is pretty 
> good, though.  Revolution needs a pure text mode
> option, but only if it 
> really works.
> 
> Since the .rev file is 95% the Transcript code in
> pure text form, I am 
> not convinced of the speed of loading issue.  One
> eye blink or two? 
> Were it tokenized, as Basic did once long ago, I
> might be more convinced.
> 
> In general, binary source code formats are the bane
> of the Linux world.
> 
> -Steve
> 

Hi Steve,

Sorry to arrive in the discussion at such a late time
but I had other things that needed attention. In the
meantime, you've received a whole range of interesting
answers.

All in all, it is perfectly possible to export a
RunRev stack to XML and bring it back afterwards. And
I'm sure that Geoff Canyon's MCRipper is an excellent
place to start.
You can iterate over the substacks and their cards and
so forth, and thus export all the information of all
the controls. This should work fine if you
base64Encode() the binary bits such as imageData.
We know what's in the built-in properties, so the only
problem I see is in determining whether a custom
property is text or binary data. Of course you could
base64encode by default, but that won't help much in
the editing department.

On to version control then ; you can always make
setProp handlers for your own custom properties, and
thus write changes to these to a log file.
Unfortunately you can't trap changes in the built-in
properties ; unless of course you use the following
trick : make a library stack to start using or place
in a backScript with the following handler
--
setProp uLOG[pProperty] pNewContent
  -- see whose property we're changing
  put the long ID of the target into tTarget
  -- now update the real property
  do merge("set the [[pProperty]] of [[tTarget]] to
[[pNewContent]]"
  -- and log the change somewhere
  WriteLogEntry tTarget,pProperty,pNewContent
end uLOG
--
Now whenever you want to update a built-in property,
and have the change logged, just use
  set the uLOG["rectangle] of field "Foobar" to \
      "100,150,300,300"
And whaddayakow, your field gets updated, and you have
a log of the change.

Of course it would be wonderful if the good people
over in Scotland could somehow tie the engine right
into CVS ; but in the meantime we're not without means
ourselves.

Hope my ideas help someone,

Jan Schenkel.

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com