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

[Keith Clarke]

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