2013/5/30 ÂÀËÎƽ <lvsongping_at_gmail.com>
>
>
> 2013/5/30 Bill Shannon <bill.shannon_at_oracle.com>
>
>> ÂÀËÎƽ wrote on 05/29/13 07:58:
>>
>> [Jeremy]Here's some points of mine:
>> 1). Do you still remember the .gfclient exists in the directory of
>> $User? Maybe we can create a file called .download_apps as a staging
>> directory under the same directory of .gfclient.
>>
>> Maybe I misunderstood...
>>
>> If the proposal is to have the *client* download the app, store it
>> locally, and then upload it to the server in the usual fashion, I
>> understand why you would need a staging directory.
>>
>> But I thought the whole point of the deployuri command was to send the
>> URI string to the server and have *the server* download the app. In
>> that case, I don't understand how a staging directory helps.
>>
> [Jeremy] I think I mentioned about the .gfclient here is not mean I
have the client to download the app, which mean that we handle the process
in the server side and download the remote application in the server side
to the staging directory, we can create the staging directory as the same
directory to the .gfclient.
> 2). If the name of the application we downloaded remotely is same
>> with the application exists in the staging area, we can delete the original
>> application in the staging area and continue to download the remote
>> application after being "verified"(if the app is downloaded to this staging
>> area and doesn't exceed the filesystem quota we would consider it ok to
>> deploy it to the real app directory)
>>
>> If you're trying to deploy a new app with the same name as an existing
>> app, the deployment should fail before downloading the app.
>>
>> If you're redeploying an app, the new version should be
>> uploaded/downloaded into a tmp location before removing the old version.
>> (I think the current upload approach always uses a tmp directory.)
>>
>> Anyway, if we don't create a directory automatic, I think the
>> following suggestion will be helpful:
>> 1). From the client side, we can also support an option called
>> --localTemp as a primary parameter to store the application downloaded
>> remotely.
>>
>> If we're going to download it to the client only to upload it to the
>> server, why don't we just let the user use "curl" or "wget" to download it
>> to the client and store it wherever they want, then use the existing deploy
>> command to upload it? Why would we need a new deployuri command for this?
>> [Jeremy]I'm sorry about that I use the wrong word
>> here, this is from the command line side but not from the client side, we
>> can also support an option called --localTemp as a primary parameter to
>> store the application downloaded remotely.
>>
>> 2). From the administrator side, we can support a virus scanning to
>> specify which directory to store the application downloaded remotely.
>> 3). Continue the operation to deploy the application.
>>
>> Again, a general hook to allow virus scanning is fine, but I don't see
>> any reason we can't just store the app wherever we would normally store it,
>> point the virus scanner at it, and if it passes then complete the
>> deployment.
>>
> [Jeremy] Sorry about that I list something wrong last time, if some of
> what I have list about the staging directory is wrong, Pls igore that. BTW,
> the whole point of the deployuri command was to send the URI string to the
> server and have the server download the app.
>