[jbosstools-dev] $0 subscription downloads - Stacks integration with download manager

[Rafael Benevides]

Hi everybody.

My first suggestion should be to use downloadUrl attribute but given 
that it's a workflowUrl I'm ok to create a label called 
downloadManagerUrl. We can't add an attribute without change the version 
(it breaks stacks-client).

I also liked to use a short version 
downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar. But it lead me 
to think If we can do something like:

*downloadUrl*=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar

This way we can continue to use the existing *downloadUrl attribute* but 
also emphasizes that this use uses a custom "protocol" that is handled 
by the downloadManager

This is my 2 cents.

Em 21/02/14 05:24, Rob Stryker escreveu:
> Rafael (and others):
>
> So I spent an hour or so yesterday chatting with David Hladky about 
> the new download manager rest services which JBosstools intends to use 
> to help us download EAP 6.x. It allows for a workflow that can help us 
> get terms and conditions, verify credentials, verify agreements have 
> been signed, and then provide a download utility with a temporary url 
> that expires to download the EAP.
>
> The api and the test server I played with look good so far. 
> JBossTools, though, pulls all of its runtime information from 
> jdf-stacks. We typically pull our download urls from there.
>
> Currently in stacks, community editions have a "url" for the project 
> page, and a "downloadUrl" for a link to a permanent url for the given 
> runtime to download.
>
> EAP instances in stacks.yaml only have a url for a project page. When 
> the download manager written by David goes live, we'll need to 
> consider what to do for stacks.yaml, and I'd prefer to get this stuff 
> sorted now.
>
> I'd like to suggest that we add a new attribute "downloadManagerUrl".  
> This will ensure clients know that this is a workflow url and not a 
> static url for downloading a file.
>
> There's 2 parts to the rest service written by David. First is the 
> rest service url itself, and the second is the file we're requesting. 
> Currently a url for one part of the rest workflow (in this example, to 
> get terms and conditions) looks like this:
>
> ${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar 
>
>
> You can see the two parts are the rest service url (on test server, 
> https://www-eng.jboss.org/download-manager/rest/tc)  and the second 
> part is what we're requesting (in this case, 
> /content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar)
>
> I see a few problems here. The first is that, in my opinion, those 
> urls are pretty long to be including in stacks.yaml... but luckily the 
> download-manager allows for shortened urls, so we could have the 
> download-manager server respond to a url like 
> ${server-root}/rest/tc?downloadURL=jboss-eap-6.0.0.dv.ci-installer.jar. The 
> download manager would then map the attribute to the 
> /content/blah/blah/sha path and proceed accordingly. So this is easily 
> fixed.
>
>
> The second, is that the rest services do not point to the next url to 
> request. For example, if I go to the tc-accepted rest service to see 
> if the terms and conditions were accepted yet, it does not point me to 
> the next url in the workflow. Because of this, there's really no 
> single entry-point in the workflow, and each rest service url is kind 
> of a standalone url.
>
> With the second point in mind, we might just want our stacks.yaml 
> attribute to say downloadManagerPath=jboss-eap-6.0.0.dv.ci-installer.jar.
>
> The client (in this case jbosstools) would pass that string to the 
> download manager rest service it chooses to use. The download-manager 
> server would resolve jboss-eap-6.0.0.dv.ci-installer.jar to its more 
> specific /content/sha256/23423823423/etc  path, and proceed normally.
>
> One concern with this approach is that the stacks.yaml will never 
> include the actual url of the rest service entry point. Even if we 
> wanted to have stacks.yaml point to the entry point, there's no one 
> entry-point since the rest services do not point to the next step in 
> the workflow.
>
> I personally have no problem using the service as it's written now, 
> and with stacks.yaml only having a shortened path available, but I 
> wanted to get your (and others) feedback on the situation before this 
> gets pushed to production, after which we probably won't have much 
> chance to change it.
>
> Any thoughts?
>
> - Rob Stryker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20140221/c39e442d/attachment-0001.html