ubuntu-appstore-developers team mailing list archive

[James Westby <james.westby@xxxxxxxxxxxxx>]

On Fri, 7 Jun 2013 09:43:19 -0300, Matias Bordese <matias.bordese@xxxxxxxxxxxxx> wrote:
> Makes sense.
> At the uploading point we already have all this information (by appid I'm
> assuming you mean the id of the respective entry in SCA?).

Whatever s-c-a wants to use, it will be opaque to click-updown. The
package name would probably make for nicer download urls, but any id
would work.

> Also, if I understood it ok and according to what I have talked, this
> upload form is supposed to directly post against click-updown, correct?

Yeah. We don't want to proxy the upload through s-c-a to confine the
long requests to one service.

> > What should the responses on success and failure be? redirects? html?
> > json?
> >
> 
> Thinking about this.
> 
> On SCA side we should get some data to relate (or build) the respective
> package click-updown download URL for the app. But we should guarantee
> somehow this is only provided back by click-updown. So maybe we need to
> have some callback in SCA where click-updown will post directly this
> information?
> 
> On the user's side, we could provide an app specific redirect URL (they
> could be different for success and failure, or expect some parameter
> indicating that). We could also include this URL in the form above.

I'm not sure how the scheme to post to a different service, but get some
information back usually works. A callback would certainly work, but
maybe some js to do the submit the form, parse the response, and use the
returned information would work.

I'm not sure that there needs to be much inforamtion transmitted
though. s-c-a only needs to know that the file was successfully
uploaded.

Maybe s-c-a needs to know if there was a source uploaded with the
binary. We can probably ignore that to start with, but it does suggest
that a channel for extra information is likely to be necessary in
future.

Thanks,

James