Difference: UWSEnhancement (1 vs. 20)

Revision 202014-05-22 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

The current working draft of the next version UWS 1.1? is on volute

Proposed changes for 1.1

documentation cleanup/clarification - some copied from the UWS section on TAPImplementationNotes

  • Section 2.1.3 HELD status - whilst this might appear to have little utility in current implementations, in future versions where there might be quotas or priorities in the UWS then HELD is a way of expressing within the UWS that the job is accepted in principle, but will not be run until some action (like freeing up some of the quota) is taken.
  • It is probably not made clear enough that the initial values of the parameters (and certainly the possible parameter names) are all established during the initial POST that creates the job and in most cases this is how the job should be driven - The ability to set an individual parameter after job creation is an additional capability that the UWS may offer - it should not offer the ability to create new parameters nor delete existing parameters - in this way a client that just creates the job with the initial POST does not "miss" out on setting a crucial parameter. We could make this clearer by removing the ability to set the individual parameter, as I believe that it was added as a "would be nice" feature without a strong use case. There is only one guaranteed way to set a parameter that all UWS services must implement - in the initial POST that creates the job.
  • Section 2.2.3.2 & 2.2.3.3, Changing execution duration & destruction time - if a service choses not to implement these features, then the standard is clear that a value of 0 should be returned for the execution duration, but I agree it is not clear what should be returned for the destruction time - in the job schema the DestructionTime element is nillable, so that would be appropriate representation in the job XML - however for the value returned at the resource URL then I agree that there is no description of what should be returned in the case where the UWS never deletes a job - you could return a value far in the future.
  • a job can be deleted at any time - it is up to the UWS server side to clean up appropriately
  • Although the current wording of the document does not make this clear enough in every case, the intention is that changing the PHASE of the job is a request by the client to the server, and the client sees whether it has been successful by examining the XML returned by the redirect to the URI /{jobs}/(job-id)/. The allowable transitions are shown by the state diagram within the document. TODO: Decide if invalid transitions should be an error
  • Attempt to update a parameter on a job that's not PENDING: a 403 [Forbidden] status should be returned
  • The text needs updating to say that creating a parameter at any stage other than the initial job creation POST is not allowed.
  • Section 2.2.3.1 defines the HTTP response code for an accepted job as 303, but does not say what should happen for a rejected job. It should do (200 plus error document??) -- MarkTaylor - 08 Jun 2011
  • The content of the /quote resource is an integer number of seconds (sec 2.1.1), but the content of the uws:quote element is xs:dateTime (schema); this mismatch seems unnecessarily confusing unless there's some rationale I'm missing. -- MarkTaylor - 29 Jun 2011
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
changes that do not break existing client implementations

  • Filtering of the JobList based on STATUS
  • Be more explicit about what parts of job can be altered in the various phases
  • directly execute a job passing through PENDING
changes that might break clients
  • add the possibility that a Job is archived at destruction time and therefore there is a new Phase "ARCHIVED" - archived jobs should keep the metadata, but not necessarily the results.
  • Suggestions in Brian Major's presentation InterOpSep2013GWS (Added to 'Results' section) - try out having result with content.

Proposed changes for later versions.

  • Call-back mechanism - Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).
Changed:
<
<
  • add possibility to re-run a job from exiting job description.
>
>
  • blocking resource
Added:
>
>
  • message with the phase
  • add possibility to re-run a job from existing job description by copying
 

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Results

  • Allow an arbitrary object to be added to the results, much like the JobInfo object.

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?
  • What about having something like OAuth, see http://en.wikipedia.org/wiki/OAuth or http://oauth.net/?
    With that people could reuse their Google or Twitter account.
<--  
-->

Revision 192014-05-21 - KristinRiebe

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

The current working draft of the next version UWS 1.1? is on volute

Proposed changes for 1.1

documentation cleanup/clarification - some copied from the UWS section on TAPImplementationNotes

  • Section 2.1.3 HELD status - whilst this might appear to have little utility in current implementations, in future versions where there might be quotas or priorities in the UWS then HELD is a way of expressing within the UWS that the job is accepted in principle, but will not be run until some action (like freeing up some of the quota) is taken.
  • It is probably not made clear enough that the initial values of the parameters (and certainly the possible parameter names) are all established during the initial POST that creates the job and in most cases this is how the job should be driven - The ability to set an individual parameter after job creation is an additional capability that the UWS may offer - it should not offer the ability to create new parameters nor delete existing parameters - in this way a client that just creates the job with the initial POST does not "miss" out on setting a crucial parameter. We could make this clearer by removing the ability to set the individual parameter, as I believe that it was added as a "would be nice" feature without a strong use case. There is only one guaranteed way to set a parameter that all UWS services must implement - in the initial POST that creates the job.
  • Section 2.2.3.2 & 2.2.3.3, Changing execution duration & destruction time - if a service choses not to implement these features, then the standard is clear that a value of 0 should be returned for the execution duration, but I agree it is not clear what should be returned for the destruction time - in the job schema the DestructionTime element is nillable, so that would be appropriate representation in the job XML - however for the value returned at the resource URL then I agree that there is no description of what should be returned in the case where the UWS never deletes a job - you could return a value far in the future.
  • a job can be deleted at any time - it is up to the UWS server side to clean up appropriately
  • Although the current wording of the document does not make this clear enough in every case, the intention is that changing the PHASE of the job is a request by the client to the server, and the client sees whether it has been successful by examining the XML returned by the redirect to the URI /{jobs}/(job-id)/. The allowable transitions are shown by the state diagram within the document. TODO: Decide if invalid transitions should be an error
  • Attempt to update a parameter on a job that's not PENDING: a 403 [Forbidden] status should be returned
  • The text needs updating to say that creating a parameter at any stage other than the initial job creation POST is not allowed.
  • Section 2.2.3.1 defines the HTTP response code for an accepted job as 303, but does not say what should happen for a rejected job. It should do (200 plus error document??) -- MarkTaylor - 08 Jun 2011
  • The content of the /quote resource is an integer number of seconds (sec 2.1.1), but the content of the uws:quote element is xs:dateTime (schema); this mismatch seems unnecessarily confusing unless there's some rationale I'm missing. -- MarkTaylor - 29 Jun 2011
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
changes that do not break existing client implementations

  • Filtering of the JobList based on STATUS
  • Be more explicit about what parts of job can be altered in the various phases
  • directly execute a job passing through PENDING
changes that might break clients
  • add the possibility that a Job is archived at destruction time and therefore there is a new Phase "ARCHIVED" - archived jobs should keep the metadata, but not necessarily the results.
  • Suggestions in Brian Major's presentation InterOpSep2013GWS (Added to 'Results' section) - try out having result with content.

Proposed changes for later versions.

  • Call-back mechanism - Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).
  • add possibility to re-run a job from exiting job description.
  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt - with email response http://www.ivoa.net/pipermail/grid/2011-May/002503.html

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Results

  • Allow an arbitrary object to be added to the results, much like the JobInfo object.

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?
Added:
>
>
 
<--  
-->

Revision 182014-05-13 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

The current working draft of the next version UWS 1.1? is on volute

Proposed changes for 1.1

documentation cleanup/clarification - some copied from the UWS section on TAPImplementationNotes

  • Section 2.1.3 HELD status - whilst this might appear to have little utility in current implementations, in future versions where there might be quotas or priorities in the UWS then HELD is a way of expressing within the UWS that the job is accepted in principle, but will not be run until some action (like freeing up some of the quota) is taken.
  • It is probably not made clear enough that the initial values of the parameters (and certainly the possible parameter names) are all established during the initial POST that creates the job and in most cases this is how the job should be driven - The ability to set an individual parameter after job creation is an additional capability that the UWS may offer - it should not offer the ability to create new parameters nor delete existing parameters - in this way a client that just creates the job with the initial POST does not "miss" out on setting a crucial parameter. We could make this clearer by removing the ability to set the individual parameter, as I believe that it was added as a "would be nice" feature without a strong use case. There is only one guaranteed way to set a parameter that all UWS services must implement - in the initial POST that creates the job.
  • Section 2.2.3.2 & 2.2.3.3, Changing execution duration & destruction time - if a service choses not to implement these features, then the standard is clear that a value of 0 should be returned for the execution duration, but I agree it is not clear what should be returned for the destruction time - in the job schema the DestructionTime element is nillable, so that would be appropriate representation in the job XML - however for the value returned at the resource URL then I agree that there is no description of what should be returned in the case where the UWS never deletes a job - you could return a value far in the future.
  • a job can be deleted at any time - it is up to the UWS server side to clean up appropriately
  • Although the current wording of the document does not make this clear enough in every case, the intention is that changing the PHASE of the job is a request by the client to the server, and the client sees whether it has been successful by examining the XML returned by the redirect to the URI /{jobs}/(job-id)/. The allowable transitions are shown by the state diagram within the document. TODO: Decide if invalid transitions should be an error
  • Attempt to update a parameter on a job that's not PENDING: a 403 [Forbidden] status should be returned
  • The text needs updating to say that creating a parameter at any stage other than the initial job creation POST is not allowed.
  • Section 2.2.3.1 defines the HTTP response code for an accepted job as 303, but does not say what should happen for a rejected job. It should do (200 plus error document??) -- MarkTaylor - 08 Jun 2011
  • The content of the /quote resource is an integer number of seconds (sec 2.1.1), but the content of the uws:quote element is xs:dateTime (schema); this mismatch seems unnecessarily confusing unless there's some rationale I'm missing. -- MarkTaylor - 29 Jun 2011
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
changes that do not break existing client implementations

  • Filtering of the JobList based on STATUS
  • Be more explicit about what parts of job can be altered in the various phases
  • directly execute a job passing through PENDING
changes that might break clients
  • add the possibility that a Job is archived at destruction time and therefore there is a new Phase "ARCHIVED" - archived jobs should keep the metadata, but not necessarily the results.
Changed:
<
<
  • Call-back mechanism - Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).
>
>
  • Suggestions in Brian Major's presentation InterOpSep2013GWS (Added to 'Results' section) - try out having result with content.
Deleted:
<
<
  • Suggestions in Brian Major's presentation InterOpSep2013GWS (Added to 'Results' section) - try out having result with content.
 

Proposed changes for later versions.

Added:
>
>
  • Call-back mechanism - Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).
  • add possibility to re-run a job from exiting job description.
 

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Results

  • Allow an arbitrary object to be added to the results, much like the JobInfo object.

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?
<--  
-->

Revision 172014-03-19 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

The current working draft of the next version UWS 1.1? is on volute

Deleted:
<
<
See also the UWS section on TAPImplementationNotes -- can we merge the material? Only keep UWS2.0 material in here?
 

Proposed changes for 1.1

Added:
>
>
documentation cleanup/clarification - some copied from the UWS section on TAPImplementationNotes

  • Section 2.1.3 HELD status - whilst this might appear to have little utility in current implementations, in future versions where there might be quotas or priorities in the UWS then HELD is a way of expressing within the UWS that the job is accepted in principle, but will not be run until some action (like freeing up some of the quota) is taken.
  • It is probably not made clear enough that the initial values of the parameters (and certainly the possible parameter names) are all established during the initial POST that creates the job and in most cases this is how the job should be driven - The ability to set an individual parameter after job creation is an additional capability that the UWS may offer - it should not offer the ability to create new parameters nor delete existing parameters - in this way a client that just creates the job with the initial POST does not "miss" out on setting a crucial parameter. We could make this clearer by removing the ability to set the individual parameter, as I believe that it was added as a "would be nice" feature without a strong use case. There is only one guaranteed way to set a parameter that all UWS services must implement - in the initial POST that creates the job.
  • Section 2.2.3.2 & 2.2.3.3, Changing execution duration & destruction time - if a service choses not to implement these features, then the standard is clear that a value of 0 should be returned for the execution duration, but I agree it is not clear what should be returned for the destruction time - in the job schema the DestructionTime element is nillable, so that would be appropriate representation in the job XML - however for the value returned at the resource URL then I agree that there is no description of what should be returned in the case where the UWS never deletes a job - you could return a value far in the future.
  • a job can be deleted at any time - it is up to the UWS server side to clean up appropriately
  • Although the current wording of the document does not make this clear enough in every case, the intention is that changing the PHASE of the job is a request by the client to the server, and the client sees whether it has been successful by examining the XML returned by the redirect to the URI /{jobs}/(job-id)/. The allowable transitions are shown by the state diagram within the document. TODO: Decide if invalid transitions should be an error
  • Attempt to update a parameter on a job that's not PENDING: a 403 [Forbidden] status should be returned
  • The text needs updating to say that creating a parameter at any stage other than the initial job creation POST is not allowed.
  • Section 2.2.3.1 defines the HTTP response code for an accepted job as 303, but does not say what should happen for a rejected job. It should do (200 plus error document??) -- MarkTaylor - 08 Jun 2011
  • The content of the /quote resource is an integer number of seconds (sec 2.1.1), but the content of the uws:quote element is xs:dateTime (schema); this mismatch seems unnecessarily confusing unless there's some rationale I'm missing. -- MarkTaylor - 29 Jun 2011
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
 changes that do not break existing client implementations

  • Filtering of the JobList based on STATUS
  • Be more explicit about what parts of job can be altered in the various phases
Deleted:
<
<
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
 
  • directly execute a job passing through PENDING
Deleted:
<
<
 changes that might break clients
  • add the possibility that a Job is archived at destruction time and therefore there is a new Phase "ARCHIVED" - archived jobs should keep the metadata, but not necessarily the results.
  • Call-back mechanism - Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).
  • Suggestions in Brian Major's presentation InterOpSep2013GWS (Added to 'Results' section) - try out having result with content.

Proposed changes for later versions.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • supply a WADL description of UWS rest to allow for automated client generation.
Changed:
<
<
>
>
 

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Results

  • Allow an arbitrary object to be added to the results, much like the JobInfo object.

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?
<--  
-->

Revision 162014-03-13 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

The current working draft of the next version UWS 1.1? is on volute

See also the UWS section on TAPImplementationNotes -- can we merge the material? Only keep UWS2.0 material in here?

Added:
>
>

Proposed changes for 1.1

changes that do not break existing client implementations

  • Filtering of the JobList based on STATUS
  • Be more explicit about what parts of job can be altered in the various phases
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • directly execute a job passing through PENDING

changes that might break clients

  • add the possibility that a Job is archived at destruction time and therefore there is a new Phase "ARCHIVED" - archived jobs should keep the metadata, but not necessarily the results.
  • Call-back mechanism - Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).
  • Suggestions in Brian Major's presentation InterOpSep2013GWS (Added to 'Results' section) - try out having result with content.

Proposed changes for later versions.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt
 

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Results

  • Allow an arbitrary object to be added to the results, much like the JobInfo object.

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?
Deleted:
<
<

Call-back mechanism

Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).

Miscellaneous

These are issues that are largely simple clarifications or enhancements of the current spec.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt
  • Copying a job to allow re-running
  • Suggestions in Brian Major's presentation InterOpSep2013GWS (Added to 'Results' section)
 
<--  
-->

Revision 152013-10-07 - BrianMajor

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

The current working draft of the next version UWS 1.1? is on volute

See also the UWS section on TAPImplementationNotes -- can we merge the material? Only keep UWS2.0 material in here?

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).
Added:
>
>

Results

  • Allow an arbitrary object to be added to the results, much like the JobInfo object.
 

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?

Call-back mechanism

Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).

Miscellaneous

These are issues that are largely simple clarifications or enhancements of the current spec.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt
  • Copying a job to allow re-running
Changed:
<
<
>
>
  • Suggestions in Brian Major's presentation InterOpSep2013GWS (Added to 'Results' section)
 
<--  
-->

Revision 142013-10-02 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

The current working draft of the next version UWS 1.1? is on volute

See also the UWS section on TAPImplementationNotes -- can we merge the material? Only keep UWS2.0 material in here?

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?

Call-back mechanism

Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).

Miscellaneous

These are issues that are largely simple clarifications or enhancements of the current spec.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt
  • Copying a job to allow re-running
Changed:
<
<

Revision 132013-10-01 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Changed:
<
<
See also the UWS section on TAPImplementationNotes -- can we merge the material? Only keep UWS2.0 material in here?
>
>
The current working draft of the next version UWS 1.1? is on volute
 
Added:
>
>
See also the UWS section on TAPImplementationNotes -- can we merge the material? Only keep UWS2.0 material in here?
 

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

Deleted:
<
<
 

More Job Controls/Metadata

Changed:
<
<
  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities
>
>
  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities
Deleted:
<
<
 

Parameters

Changed:
<
<
  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).
>
>
  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).
 
Changed:
<
<

Authentication and Authorization

>
>

Authentication and Authorization

 
Changed:
<
<
  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?
>
>
  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?
 
Deleted:
<
<
 

Call-back mechanism

Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).

Miscellaneous

Changed:
<
<
These are issues that are largely simple clarifications or enhancements of the current spec.
>
>
These are issues that are largely simple clarifications or enhancements of the current spec.
 
Changed:
<
<
  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt
  • Copying a job to allow re-running
>
>
  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt
  • Copying a job to allow re-running
 
Changed:
<
<

>
>

Deleted:
<
<

Revision 122012-06-26 - root

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

See also the UWS section on TAPImplementationNotes -- can we merge the material? Only keep UWS2.0 material in here?

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?

Call-back mechanism

Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).

Miscellaneous

These are issues that are largely simple clarifications or enhancements of the current spec.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt
  • Copying a job to allow re-running


Revision 112011-10-20 - MarkusDemleitner

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Added:
>
>
See also the UWS section on TAPImplementationNotes -- can we merge the material? Only keep UWS2.0 material in here?
 

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?

Call-back mechanism

Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).

Miscellaneous

These are issues that are largely simple clarifications or enhancements of the current spec.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt
  • Copying a job to allow re-running


<--  
-->

Revision 102011-10-20 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?

Call-back mechanism

Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).

Miscellaneous

These are issues that are largely simple clarifications or enhancements of the current spec.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt
Added:
>
>
  • Copying a job to allow re-running
 


<--  
-->

Revision 92011-05-23 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?
Added:
>
>

Call-back mechanism

Rather than having to poll job status it would be nice if there were a mechanism whereby a client could be notified when the job changes status (possibly easier to do in a non-REST binding).

 

Miscellaneous

These are issues that are largely simple clarifications or enhancements of the current spec.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt


<--  
-->

Revision 82011-05-19 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?

Miscellaneous

These are issues that are largely simple clarifications or enhancements of the current spec.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
  • VOParis suggestions http://voparis-srv.obspm.fr/doc/uws-v2.0.txt


<--  
-->

Revision 72011-05-19 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls/Metadata

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?

Miscellaneous

These are issues that are largely simple clarifications or enhancements of the current spec.

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
Added:
>
>
 


<--  
-->

Revision 62011-05-18 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

Changed:
<
<

More Job Controls

>
>

More Job Controls/Metadata

 
  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities
Changed:
<
<
  • Authorization and Authentication issues...
>
>
 

Parameters

  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).
Added:
>
>

Authentication and Authorization

  • Authentication covered by IVOA SSO spec, but is that easy to use enough?
  • Do we want to specify some simple Authorization controls for a job?
 

Miscellaneous

Added:
>
>
These are issues that are largely simple clarifications or enhancements of the current spec.
 
  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
  • supply a WADL description of UWS rest to allow for automated client generation.
Deleted:
<
<
 


<--  
-->

Revision 52011-05-17 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities
  • Authorization and Authentication issues...
Changed:
<
<

Miscellaneous

>
>

Parameters

 
Added:
>
>
  • enhanced parameter description - how far to go?
  • change recommendation of parameter URIs as in UWS 1.0 2.1.11 to be a stronger "should" to allow for a well known place for inline uploaded parameters to be re-read (as a "byReference" parameter in the job description).
 
Added:
>
>

Miscellaneous

 
  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
  • Be more explicit about what parts of job can be altered in the various phases
Added:
>
>
  • supply a WADL description of UWS rest to allow for automated client generation.
 


<--  
-->

Revision 42011-05-17 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities
  • Authorization and Authentication issues...

Miscellaneous

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
Added:
>
>
  • Be more explicit about what parts of job can be altered in the various phases
 


<--  
-->

Revision 32011-05-15 - MarkTaylor

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Alternative bindings to REST

SOAP Binding

A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project

Other binding

There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities
  • Authorization and Authentication issues...

Miscellaneous

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
Added:
>
>
  • Standardise behaviour when server rejects job creation (UWS 1.0 sec 2.2.3.1)
 


<--  
-->

Revision 22011-05-09 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.

Added:
>
>

Alternative bindings to REST

 
Added:
>
>

SOAP Binding

 
Added:
>
>
A SOAP binding was removed from the original draft of the version 1.0 standard - This could be reintroduced for the next version - A possible WSDL file for this binding is contained within the volute googlecode project
 
Added:
>
>

Other binding

 
Added:
>
>
There have been requests for other bindings that include the operations on the UWS objects directly as part of the XML message.
 
Added:
>
>

Registering UWS implementations

"Pure" UWS implementations - i.e. a UWS that is not part of another IVOA standard - have been created, and people would like to register these directly - This needs a specific VOResource extension. A start to this is being made with UWSRegExt

More Job Controls

  • Quotas - on storage and CPU + ability to query remaining Quota
  • Priorities - allow jobs to have settable priorities
  • Authorization and Authentication issues...

Miscellaneous

  • Progress attribute for a Job - have option estimate of percentage completion for a job
  • RunID returned in the JobList
  • Filtering of the JobList based on STATUS
 


<--  
-->

Revision 12011-04-12 - PaulHarrison

 
META TOPICPARENT name="AsynchronousHome"

Enhancement Requests to UWS 1.0

This page is intended to summarize various suggestions that are made to enhance UWS to determine if they should be included in the next major version of the UWS standard. The discussion of individual topics will take place primarily on the grid wg mailing list.


<--  
-->
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback