David, I'm looking forward to the discussion next week - and also a better mechanisms for shared content. Thanks for taking the initiative on that.
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?" 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'?". 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. ;-) Best, Keith.. On 23 Jan 2011, at 13:37, David Bovill wrote: > On 23 January 2011 12:56, Keith Clarke > <keith.cla...@clarkeandclarke.co.uk>wrote: > >> >> Yesterday's Live LiveCode Code event sessions touched on documentation and >> wiki possibilities. Whilst a key focus here will be on improving the 'What?' >> and the 'How?' of using LiveCode's functions, could there be room for these >> issue of Where/When/Whether to use functions, controls, externals, third >> party components, etc., by deployment type? >> > > Hi Keith, I agree with you, and it is a central part of the content that I > think we need. Where/When/Whether translates for me to: > > - Where - an updated snapshot of supported platforms, what is and what is > not supported in terms of features > - When - an updated roadmap of features. The hard facts, and the soft > directions. > - Whether - things you should and should not plan for in a project. > Rumours vs best practice > > These elements are possible to address, as part of a general community > publication, but I think there are not enough resources for this as a > standalone publication. I believe they should be associated with the > existing documentation, and linked to an open source publication of useful > code, libraries and widgets. > > At the next LiveCode TV event, I'll show the new distributed wiki, and how > that can glue the documentation, code samples and your Where/When/Whether > together in a way in which everyone has there own local content, but sharing > is transparently done in the background. > _______________________________________________ > 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
