A Text file format for LiveCode

[Monte Goulding]

On 07/10/2013, at 6:20 AM, Alejandro Tejada <capellan2000 at gmail.com> wrote:

> If LiveCode Community had, for default, a text file format
> for LiveCode stacks, How could this benefit developers
> and the platform at large?
> 
> http://newsletters.livecode.com/october/issue158/newsletter1.php
> 
> Thanks in advance!

Hi Alejandro

The myth that LiveCode having a native text file format would solve all the problems I've been trying to tackle with lcVCS is just that.. myth. The two significant issues I mention in that article still need to be overcome. 

The first is that our stackFiles save session data etc that needs to be cleared or reset to defaults during the save so it doesn't cause conflicts. It might be possible to resolve in the engine, however, that might involve having to set default values for many properties so the engine would know what to export and I think it would be unworkable in practice. Imagine the example I use in the article of a resizeStack handler. You want your code to run when resetting the size of the stack. 

The second is the ID issues I've discussed on various lists a number of times which can be resolved at engine level but it doesn't look like we have support for that from RunRev.

There are also many benefits in using the very compact binary file format that our stackFiles are saved in. It shouldn't be underestimated either. For example I have a 6KB stack I use as a testbed for lcVCS and exported as text it is 336KB. Imagine 8 boolean properties. In a binary file format you can store them in a single byte. In a text file format you need to write out the name of each property and it's value.

On the up side I'm getting pretty close to the best of both worlds with lcVCS. The engine saves it's stackFile and lcVCS is automatically run as a separate process using a command line interface to export it. Git hooks re-build the stackFiles after a checkout, merge or rewrite as long as the merge didn't have conflicts. If it did then you import and resolve conflicts using the plugin. The workflow is getting fairly close to what you would have with any other platform other than there's a little delay between your save and the text representation being available to commit.

Of course you may be wanting to discuss just changing to a text format but not being interested in version control. If so then I'd struggle to see any benefit at all.

Cheers

--
Monte Goulding

M E R Goulding - software development services
mergExt - There's an external for that!