UWS joblist implementation issues

[Petr Skoda]

Hi Pat and others,


> implementation to not allow the client to GET the joblist. We simply return an
> HTTP "forbidden" (403) response.
> it protects users of our system from others looking at their jobs (TAP
> queries, VOSpace transfers, etc), although that protection is "security-by-
> obscurity"

I will comment on this from the point of view of our VO-KOREL service 
which is UWS-based but using WEB browser to interact with.

In this case the users are authenticated by https (using password at 
the begining) and they expect the same behaviour  as in e-shop - to see 
only their "shoping cart" - i.e. the list of jobs they have initiated (may 
be some long computations and they want the freedom of cancelling job 
which seems to not give results (e.g. by checking the convergence file 
where the iteration progress is updated by the computing code).
The joblist is a main control element for their decision and a kind of 
"laboratory log" or notebook - they see all their experiments (parameters 
combination and results) and the status of jobs (e.g. still not fed to 
queue, crashed etc. - even the cancelled may be restarted - e.g. when the 
task is urgent).

I am pretty sure that the final form of UWS pattern should converge to 
something like this. It was as well part of my criticism of current UWS 
that it does not support too much such a "housekeeping" function in web 
client (e.g. comments, free job labeling etc ...).

OTOH it is clear that the usage of UWS in VOSPACE transfer or TAP is 
conceptually different from cloud computing usage in a manner of 
"supercomputer experiment on your mobile " ;-)

I would personally prefer to filter the joblist using the users 
credentials to give him/her the sense of privacy and personalisation (even 
the VOSPACE transfer - it may teach him the efficient way of bandwidth 
usage if he/she sees the amount of transfer requested by him/her .... 
maybe I am naive ;-)

> complete job list may be very large (currently ~462,000 jobs). We could keep
> it manageable by deleting jobs after some time (as described in the
> destructionTime field) but the output of GET /joblist could be a large-ish XML
> document.

I think the user should decide about deleting old information himself (in 
addition to automatic expiration) - in fact he will be bothered to see the 
long list in his browser every time ;-)

> implementation, that would result in a forbidden response: *not* forbidden to
> delete the job (it will be deleted) but forbidden from seeing the resulting
> joblist. That's definitely going to be odd.

and extremely confusing - I guess many users will start to ask what is 
wrong with the server ...... (normal reaction when the browser does not 
show the content but strange http error - even the http REDIRECT confuses 
people and instead of waiting they  reload the page again and again ....


But as I said I do not have idea how it works in large data center - what 
is a typical structure of UWS usage.

BTW - in UWS1.0 it was postponed the precise definition of job expiration 
behaviourand some concepts of queue priorities AFAIK for later versions.



> suspect that users really expect even their anonymous activity to be private
> so it might not be sufficient to only offer privacy as an opt-in feature :-)

Exactly - the e-shop concept is very tempting .....
And I can imagine PI's accessing their  data in proprietary period using 
certificates thinking about them as about theirs property (the concept of 
governmental funding is usually understood one-way only accoridng to my 
experience with stellar community (I want everything be public but my 
results are available only after I decide - long time (if ever) 
after publication - and still not giving out the all) - but its another 
storry .....

*************************************************************************
*  Petr Skoda                         Phone : +420-323-649201, ext. 361 *
*  Stellar Department                         +420-323-620361           *
*  Astronomical Institute AS CR       Fax   : +420-323-620250           *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Czech Republic                                                       *
*************************************************************************