ubuntu-appstore-developers team mailing list archive

[Matias Bordese <matias.bordese@xxxxxxxxxxxxx>]

On Fri, Jun 7, 2013 at 12:12 PM, Ricardo Kirkner <
ricardo.kirkner@xxxxxxxxxxxxx> wrote:

>
>
>
> On Fri, Jun 7, 2013 at 11:28 AM, James Westby <james.westby@xxxxxxxxxxxxx>wrote:
>
>> 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.
>>
>
> Mhh, the upload should end up in click-updown, but since the click app is
> being submitted to s-c-a, this is a bit odd. Does this mean we have to
> submit part of the form to s-c-a (package metadata, etc) and other parts to
> click-updown (actual file)? It makes sense not to bog the s-c-a service
> down with a large file, but this sounds like the upload step in the
> submission form has to be completely separated from any other metadata, so
> that the form is sent directly to click-updown.
>

The package metadata is collected in the previous steps, so we already got
all the details when reaching the upload form (and we can post this data
along the file upload). In the upload step we would be only asking the user
for the binary app and optionally the source.