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.cla...@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@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
