Business Application Framework

[Mark Waddingham]

> I’m not convinced it’s a killer. I just think it needs some special
> tools. It really wouldn’t be that hard to build a third party code
> review web app that integrated with GitHub via service hooks. Such a
> beast would know the export stack file format and present the objects
> in the same way the project browser does with visual representations
> etc.

To be fair it is a killer if you do not have such a front-end and want 
to have multiple people working in a rigorous way on a single LiveCode 
project ;)

As I said, that option was discussed and I (personally) didn't think it 
too bad an idea in principal - but it wasn't considered a viable option 
at the time (it added another required layer to the system in order to 
ensure it met the requirements we had of it) and it did suggest that 
perhaps reconsidering the approach was the best way forward to producing 
a fully cohesive solution. It essentially reduces the git/github choice 
to being a storage backend which isn't really something for humans to 
look at. Our feeling at the time was that we really wanted a solution 
which was entirely 'natural' in GitHub.

Of course hindsight is 20/20 and perhaps the front-ending should be 
revisited to see how integrated and natural it could be made. GitHub is 
obviously an important and powerful force in the world of modern 
software development (whether Open or Closed), but we have to ensure 
that LiveCode's use of it does not seem 'perverse' - otherwise it just 
gives another reason for people not to consider LiveCode. (Given that 
LiveCode already 'goes against the grain' in a number of ways, we don't 
really want to make the job any harder!).

 From the point of view of the work Peter did put into VCS, none of it 
has been wasted. The 'stackdir' format we came up with is perhaps not 
the important point (I'm sure Monte, Peter and I could spend many hours 
finessing such a format to ensure it is bomb-proof, mitigates merge 
conflicts as much as possible and is actually tractable on modern FSs - 
Windows being a bit of a bear) - at the end of the day it just an 
on-disk representation of an in-memory data structure.

 From an engine perspective it is probably the underlying 'stackarr' 
encode/decode which is the critical piece which has much wider 
applicability and the bit which would be high on the list to finish 
first. It does for stacks and objects the same thing the 'styledText' 
array format does for fields - it allows you to naturally manipulate the 
structure of stacks using arrays in script in a very direct way. Much 
more easily then having to introspect directly on live objects and the 
lcVCS or stackdir import/export could be implemented in script based 
upon it. The 'stackarr' concept has benefits elsewhere too - for example 
the project browser has to extract the information describing an object 
to do its job, as does the property inspector; and I know there are lots 
of tools out there which also replicate exactly the same process in one 
way or another (lcVCS just being one example).

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps