ubuntu-appstore-developers team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

On Mon, 2 Sep 2013 10:02:00 -0300, Ricardo Kirkner <ricardo.kirkner@xxxxxxxxxxxxx> wrote:
> Hello everyone,
> 
> I'd like to start the work to allow uploading click packages to the
> AppStore directly from within the SDK by proposing some ideas and getting
> feedback on them.
> 
> The current goal, as we understand it is to:
> - allow developers to upload a new click package directly from the SDK
> - allow developers to upload an update to an existing click app directly
> from the SDK
> 
> In order to meet these initial goals I propose the following approach:
> 
> 1. Provide an API in the Click-Updown service that
> - allows uploading a click app
> - is authenticated
> - will verify the uploaders credentials to correspond to an existing Ubuntu
> One account
> - will verify the requested application already exists in the MyApps catalog
> - will verify that the uploader is the application owner (or has the
> equivalent permissions)

As discussed on IRC earlier, I don't think this is needed. Getting the
hmac-signed form from sca for the app will get you what you need to be
able to upload to click-updown using the existing api.

> 2. Write a reference implementation library that knows how to interact with
> - the Ubuntu One account API to validate the user's credentials and embed
> them properly into the upload request
> - the Click-Updown API to submit the upload request
> 
> 3. Write a reference implementation script that will allow simple uploading
> of click packages from the CLI
> 
> Limitations
> ----------------
> 
> In the first iteration, the click app must already exist in the MyApps
> catalog, and the user will be requested to create it through the web if
> that is not the case. In future iterations this might be extended to allow
> registering the app directly from within the SDK.
> 
> The initial version of these APIs will only support uploading of click
> packages, but not publishing them automatically. Changes the to state of a
> click app must be performed by following the existing web-based review
> flows.

We've decided that all interactions with sso and pay should be through
the browser, embedded if needed, to make the flow easier to change. I
think we should be aiming for the same approach here, with the
interaction being done in a browser embedded in the sdk, with the sdk
only knowing enough to 'pre-fill' the things that it can.

I'm not sure how that works, but we should be careful not to repeat
mistakes of the past on new projects.

Thanks,

James