<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 2008-05 -20, at 16:08, Guy Rixon wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> Hi,</div></blockquote><div><br></div>It is a shame that the session on this is at the end of the week, as some of the requested changed will make more sense after a demonstration.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Paul Harrison reported (<a href="http://www.ivoa.net/internal/IVOA/AsynchronousHome/ImplementingUWS-0.1.pdf">http://www.ivoa.net/internal/IVOA/AsynchronousHome/ImplementingUWS-0.1.pdf</a>) on a UWS-0.3 implementation and suggested some changes to the UWS pattern. Here are some responses.</div><div><br></div><div><b>Change the way a job is committed for excution to "post to phase resource".</b> I accept the advantage of the client not addressing the quote object. Would it be better to allow the client to HTTP-put the phase resource? Or HTTP-post with phase=run to the job resource itself?</div></div></blockquote><div><br></div>I chose POST rather than PUT because this is a request to change state, - the service might not be able to respond immediately, so a GET straight after might still return the PENDING state - if this were PUT you would expect to get the value back that you PUT. </div><div><br></div><div>I think that the question of whether to POST to the job object instead is an open issue for all of the sub objects. I have no particular personal preference for either, but chose POSTing direct to the sub-object, as this pattern had been used already, so I followed that.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><b>Extra job state "ABORTED".</b> Yes we could add this. Is there a particular use case that needs it?</div></div></blockquote><div><br></div><div>Needed because for a job that has been stopped before its destruction time it is useful to know exactly how it terminated (as I have termination and abortion not implicitly deleting the job)</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><b>Distinguish termination time from destruction time. </b>This could work, but is it really needed? For setting the times, HTTP-put would be preferred.</div></div></blockquote><div><br></div>I think that it is actually a very useful addition to the pattern (and in fact the only one that could not be considered in some way cosmetic). It allows you to potentially use the UWS output of one job directly as the input to the next job in a workflow, without needing to go via vospace. </div><div><br></div><div>Termination time could be viewed as a CPU time limit (and as such perhaps an absolute real time is not such a good idea - a period of CPU seconds be better) - Destruction time could be viewed as a data storage time limit.</div><div><br></div><div>My justification for using POST is that again this is can only be viewed as a request to change the times - the server might have policies that prevent you from setting the time exactly as requested.</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><b>Error object.</b> I concur. Since the error has its own resource, I guess the service could use an HTML representation if the client accepted such.</div><div><br></div><div><b>Require action=DELETE on job-destruction posts.</b> Accepted; it's a good safeguard.</div><div><br></div><div><b>Composite metadata.</b> I agree with the principle. We need to look very closely at the implementation.</div><div><br></div><div><b>XML and HTML representations. </b>UWS 0.2 did use the stylesheet link to transform in the browser as Paul suggests. I went to the other technique for 0.3 partly to get a comparison and partly to work around some J2EE issues in a quick implementation. I'm happy to go back to client-side transformation for the next draft.</div></div></blockquote><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><b>"Reload later" (503) response</b>. I'm not clear when this is to be used. Is it instead of a 404 when an output isn't ready?</div></div></blockquote><div><br></div>yes - I am trying to do this if you ask for a result before it is ready.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> </div></div></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>Dr. Paul Harrison</div><div>JBCA, Manchester University</div><div><a href="http://www.manchester.ac.uk/jodrellbank">http://www.manchester.ac.uk/jodrellbank</a></div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></span></span></span></div></span> </div><br></body></html>