<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi everybody.<br>
<br>
My first suggestion should be to use
<meta charset="utf-8">
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).<br>
<br>
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:<br>
<br>
<b>downloadUrl</b>=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar<br>
<br>
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<br>
<br>
This is my 2 cents.<br>
<br>
<div class="moz-cite-prefix">Em 21/02/14 05:24, Rob Stryker
escreveu:<br>
</div>
<blockquote cite="mid:53070D2D.7090302@redhat.com" type="cite">Rafael
(and others):
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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:
<br>
<br>
${download-manager-server}/rest/tc?downloadURL=/content/origin/files/sha256/42/42a9766b4914af02350a39612eb587170e7bf079143cc70886c9cf33022b433c/jboss-eap-6.0.0.dv.ci-installer.jar
<br>
<br>
You can see the two parts are the rest service url (on test
server, <a class="moz-txt-link-freetext" href="https://www-eng.jboss.org/download-manager/rest/tc">https://www-eng.jboss.org/download-manager/rest/tc</a>) 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)<br>
<br>
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.
<br>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
Any thoughts?
<br>
<br>
- Rob Stryker
<br>
</blockquote>
<br>
</body>
</html>