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

[Fred Bricon]

*downloadUrl*=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar will 
not be supported by existing JBT/JBDS clients

Le 21/02/2014 19:06, Rob Stryker a écrit :
> On 02/21/2014 10:41 PM, David Hladky wrote:
>> Hi Rob,
>>
>> will you also use the part of the interface, that would allow the user to accept the terms and conditions in Eclipse? It may look better if you do.
>>
>> David Hladky
>
> Yes, David, we will definitely be using that part of the interface.
>
> Considering that the download-manager is set to be released and in 
> production soon, I'm really not sure I can expect your team to make 
> changes to the workflow, responses, etc.  I think at this point it's 
> more likely to break stuff. But I'll list the problems so far:
>
>    1) Each rest entry point response does not point to the next step 
> in the workflow
>    2) This means a client (like jbt) must assume the workflow
>    3) This means that if you guys need to add steps to the workflow in 
> the future, you can't, without breaking clients
>    4) It also means that we must hard-code each url (tc, tc-accepted, 
> tc-accept, file) and that these become API and can never be renamed.
>    5) Even if you added the next url as part of the response, your 
> initial entry point is basically the service "tc-accepted",  which 
> seems a strange name to begin the workflow.
>
> The only part of this I see as 'dangerous' really is item 3) and 4).   
> You guys won't be able to add steps to the workflow without breaking 
> clients. Item 1) is annoying, though, as it means we can't simply put 
> the url to the download-manager with its attribute in stacks.yaml.
>
>
> Considering time is tight and I doubt the download-manager team can 
> make the changes above, For stacks.yaml, I like Rafael's suggestion:
>
> *downloadUrl*=downloadManager://jboss-eap-6.0.0.dv.ci-installer.jar
>
> JBT would then recognize the prefix, chop it off, and use that string 
> as what we pass to download-manager's rest services. Perhaps stacks 
> can have a property somewhere in its client jar that lists the 
> download manager's root url, to avoid multiple clients having it 
> hard-coded everywhere. (Rafael, if you think it doesn't belong there, 
> I guess jbt can just have it hard-coded or pulled from somewhere, but 
> I think if stacks is listing download-manager urls in the stacks.yaml, 
> it should list the URL of the rest services somewhere, for example 
> inside jdf-stacks-client / src / main / resources / org / jboss / jdf 
> / stacks / client / config.properties where you list the stacks url 
> and pre-stacks url)
>
> Assuming Rafael's solution doesn't offend anyone, I think it's the 
> best we have for now.
>
>> ----- Original Message -----
>> From: "Rob Stryker"<rstryker at redhat.com>
>> To: "David Hladky"<dhladky at redhat.com>, "Rafael Benevides"<benevides at redhat.com>, "Snjezana Peco"<snjezana.peco at redhat.com>, "jbosstools-dev jbosstools-dev"<jbosstools-dev at lists.jboss.org>
>> Sent: Friday, 21 February, 2014 9:24:13 AM
>> Subject: $0 subscription downloads - Stacks integration with download manager
>>
>> 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
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

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