Feature support by deployment type - the state of the art?

[Keith Clarke]

David,
I concur with everything you're suggesting. I deliberately put 'database' in quotes as it's the relational data concept, rather than the specific technology for persistence that I had in mind. 

Sorry but I can't help too much with any database issues - or any other technical areas really - my interest is at a more functional than technical level. I asked the original question as I'd like to add to my toolkit of high-level LiveCode components that I buy, apply and integrate, rather than have to code from scratch.

Of course, the use of these high-level components would bring added complexity around the combinations and permutations of functional blocks that might create forking/branching of documentation - and not just at the feature/function level, as (for example) ChartMaker and ChartEngine would doubtless have different internals and 'API' to perform similar functions, as would Data Tree vs. rTree and similar variations on a theme. 
Best,
Keith..      

On 24 Jan 2011, at 12:16, David Bovill wrote:

> On 24 January 2011 11:32, Keith Clarke
> <keith.clarke at clarkeandclarke.co.uk>wrote:
> 
>> 
>> However, whilst a wiki might help with 'How-to' documentation, I'm not sure
>> it would be the ideal solution to address the core data and process
>> management issues here. There is a need for structure and clarity around
>> entities (platforms, controls, components, script features, etc),
>> relationships (e.g. the degree of feature support) and implications of
>> change. These suggest the need for cross-referencing, tables and therefore a
>> core 'database' to me. Indeed, many questions and information gaps (and
>> potential wiki content) are around inner vs. outer joins - "Does this
>> component run on this deployment?", "Exactly what does 'cross-platform' mean
>> for this component?"
>> 
> 
> Exactly! But I believe we can have all this without reaching out immediately
> for a database solution.
> 
> The solution I am working on has the documentation and code both in the
> repository. That way you can simply rewind to any particular IDE engine
> release to see the documentation and code suitable for that environment.
> 
> Moving forwards any new features added to the engine and IDE would be
> documented by the community based on the release notes, and linked to
> tickets for bug fixing. As the bugs get fixed and questions answered these
> would get moved into the documentation wiki. Official releases would be
> tagged, and users would be able to work within  a tagged release branch, or
> in a beta environment branch.
> 
> The thought is to use branches for different specific use cases. From
> pushing at the boundaries of what is possible with distributed version
> control and git in particular, it would appear that the technical
> infrastructure is there to support all these issues - but that the specific
> use case demands using branching and other features to deal with the
> particulars of multi-platform development.
> 
> This approach will rely on getting the usability issues right, and shielding
> the intricacies of the repository from the causal developer - but in
> principle they should be able to work in a branch that is specific to a
> platform or combination of platforms.
> 
> I should also note that as the code and documentation would be in the
> repository - this does not exclude the use of the sort of databases you
> indicate. The current implementation is going to use sqlite to hold both the
> repository itself and various indexes used to search it. I feel this can be
> built on.
> 
> Ideally, in order for this to be of use for people with older licenses, I
> would import a historical series of snapshots, which would allow people with
> older versions to work.
> 
> There are many aspects of this that I am unclear about, with regards to how
> branching and merging, and other features or distributed repositories can be
> used in this mix - but the initial benefits are simple and clear - shared
> collaborative code and documentation that is available offline and easy to
> customise to local needs.
> 
> So, maybe a core database with relationships and structured data, could link
>> out to comments, extended commentary and other wiki-style verbose content to
>> answer formally structured questions such as - "How do I do function 'A'
>> with component 'B' if deploying to environment 'C'?", together with loosely
>> structured questions "What components could I consider buying to save
>> building functions 'x', 'y' and 'z'?".
>> 
> 
> I'm certainly open to building a database on top of the version controlled
> documentation and code. This db is more advanced that I am practiced at
> building, and if you have any tips / input that would be great. For now I am
> exporting the vital information that needs versioning as text files, and
> indexing these in sqlite. This should be a solid basis to build more
> extensive queries on.
> 
> Back to my original question, it would have been nice to see in the RunRev
>> Store a simple table of which third-party components can be deployed where
>> but I guess anything that risks shattering the illusion of universality is
>> against RunRev's interests, so I won't hold my breath. ;-)
>> 
> 
> There is a sensitive issue for RunRev here - and an approach where the
> community can offer on a separate site an analysis of this issues, which is
> open to investigation by any interested party but clearly separate from
> marketing and / or official company policy is a way in which all parties can
> have their cheese and eat it.
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode