Re: [jbosstools-dev] $0 subscription downloads - Stacks integration with download manager
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.
The original idea was that downloadUrl would be sufficient and then just
a label
to mark it as something that can use the download manager api and the
tools would
know the url to use for that download mechanism (maybe we could have the
label be:
downloadmanager: <initial-resturl> ? and you look up that label and know
what to start from?)
Is that no longer an option ?
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
Irrelevant. Those urls are already used on our download pages so I don't
see that as a big issue at all.
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.
Sounds like something that should get fixed in the download service ?
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.
Rather fix the download service so no such weird details has to leak
into stacks.yml.
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.
lets fix the service to be complete then ?
/max