UbuntuSDK
Expectations
- We want to kick off the discussion about the criteria to choose to decide on a future SDK
- We're not going to work on an Ubuntu SDK this cycle
- We want to discuss what an SDK should really include
Criteria
- Integration with Ubuntu (which bindings would be required?)
- Language/Toolkit support or potential for it should be considered
- (for example: Python bindings for Canberra sound playing)
Form factor support & performance
- Availability of documentation
- Stability/Maturity/Support life
- application sandboxing
- abstraction from actual implementation
concept of a 'well-behaved' app that uses all recommended approaches an therefore is likely to work well on the wide range of form factors
clear statement of support period for apps that implement recommended APIs
Provide some guarantee of support lifetime, minimum amount of time in deprecated
(I would also make it clear that no component of this SDK can be "Ubuntu only". Anything built against the SDK must be buildable on other distros too. Otherwise we're causing bad disruption that will just scare off devs. -afeder)
What should an SDK include?
- API set
- Root file system + container (debatable whether this should be included or whether the SDK should be released as applying to specific Ubuntu release)
- Toolset
- Ecosystem (back end)
- Whatever supports the app lifecycle
- Documentation
Areas of coverage
- GUI
- Audio
- Video
- Networking / http I/O
- File I/O
- Localization
- Accessibility
- Internationalization support
- Test coverage
- Data syncing
- Online accounts/credentials
- Background processes/service
- User configuration/settings
- Tools/IDE/Compilers/Packaging
- Metadata (see Tracker/NEPOMUK)?
- indicator support
- notification support
- app documentation
Work items
- [dpm] Cre
- [stefano-palazzo] Research the bindings the libraries we are recommending support
UbuntuSDK (last edited 2012-10-30 05:21:58 by 2909ds4-vbr)