Question on .rev file format

Steve Gehlbach steve at nexpath.com
Sat Aug 2 17:03:01 EDT 2003


Thanks for the careful reply.

I am not sure about XML, some reports on the net indicate is has bloat 
tendencies, but I have no personal experience.  It it already done, so 
that is a plus.

The comments on version control were over my head, but as I continue to 
learn RR maybe the fog will clear.

-Steve

Jan Schenkel wrote:
> --- 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
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution





More information about the use-livecode mailing list