I'd like to suggest that we add a new attribute
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
to mark it as something that can use the download manager api and the
know the url to use for that download mechanism (maybe we could have the
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
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:
You can see the two parts are the rest service url (on test server,
) and the second
is what we're requesting (in this case,
I see a few problems here. The first is that, in my opinion, those
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
request. For example, if I go to the tc-accepted rest service to see
the terms and conditions were accepted yet, it does not point me to
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
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
Rather fix the download service so no such weird details has to leak
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
lets fix the service to be complete then ?