Launchpad Entry: appdevs-ubuntuone-n-apis
Created:
Contributors: sil
Packages affected:
Summary
Ubuntu One has APIs available but they need to be easy for those building new applications or wanting to integrate Ubuntu One services into existing applications. This includes providing wrapper APIs on existing Ubuntu One functionality (across the various services, files, contacts, etc.) along with reference documentation and examples.
APIs should be available to the Ubuntu desktop, to mobiles, to web applications: everyone should be able to make their apps better with Ubuntu One.
Part of this session is about not just which APIs applications need, but also where those APIs should be talked about; documentation for those APIs, where should it live? How do we get the word out to application developers? Which applications would be good to point out as "flagships", that demonstrate how to do this? If you're an application developer, what do you need from Ubuntu One?
Suggested APIs to provide, for discussion:
Desktop APIs:
- publish file
- share folder/unshare folder
- add/remove a folder to/from ubuntu one
- stream music (?)
- desktopcouch
- desktopcouch-health-monitor program to show which DBs are synced and when
- they last synced, to help debugging and awareness
- start up signup window to allow someone to join U1 (you choose "sync my
- data using Ubuntu One" in the app, but you're not signed up/signed in)
- is Ubuntu One available on this machine? (makes it easy to hide U1 features
- on Fedora)
- get a u1ms link and preview URL for a given song (if you have song
- metadata: title, artist, album; musicbrainz id) (wrapper around web API)
Web APIs:
- REST file API
- share a folder (for vds fullcircle idea)
- document /phones/creds/{android,ios}
- SSO and how to get a token valid for U1 in your app
- get a u1ms link and preview URL for a given song (if you have song
- metadata: title, artist, album; musicbrainz id)
- CouchDB per-db access, readonly access (needs admin on website to see and remove tokens granted to an application)
Release Note
Rationale
User stories
Assumptions
Design
You can have subsections that better describe specific parts of the issue.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
UI Changes
Should cover changes required to the UI, or specific UI that is required to implement this
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
Test/Demo Plan
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.
This need not be added or completed until the specification is nearing beta.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.