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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
