[rus-wg] RUS Specification - users

Jon MacLaren maclaren at cct.lsu.edu
Thu Apr 7 14:55:59 CDT 2005


Thinking about this, I think you are right.  It would be easy to make 
this optional.  Implementations could choose to allow this or not.

Jon.


On Apr 7, 2005, at 11:09 AM, Sven van den Berghe wrote:
> Jon,
>
>  So the two users are the minimum necessary for an service, but I can 
> see
> that some implementations will want to add more, so this possibility 
> should
> not be excluded. Some of the text seems to do this e.g. In the
> RUS::extractRecords (Section 5.5.1).
>
> Sven
>
>
> "Jon MacLaren" <maclaren at cct.lsu.edu> wrote:
>
>>
>> On Apr 6, 2005, at 8:42 AM, Steven Newhouse wrote:
>>
>>>>  In the document you identify only two classes of user as having
>>>> access to
>>>> data stored within the RUS - I guess that you mean the ability to
>>>> view and
>>>> modify URs. Should you also note that there are classes of user that
>>>> have
>>>> only read access - the grid user running jobs should be able to view
>>>> her
>>>> URs, PIs can view the URs of a project, VO manager can view the URs
>>>> of jobs
>>>> from her VO etc (all requiring access policies etc)
>>>
>>> The OGSI version of the RUS specification had slightly richer user
>>> model... but I feel the current model reflects better the operational
>>> reality. How many of these users/PIs will want to be generating
>>> XPath/XQuery statements to extract data from a web service? Probably
>>> very few.
>>
>> I believe that the motivation for changing the model was to prevent
>> many users (e.g. hundreds in the case of Manchester's CSAR-wide RUS)
>> slowing the RUS down with arbitrary queries.  At Manchester, a portal
>> was provided - but of course, this is outside the scope of the spec.
>> Doing things this was gives a mechanism to limit the sorts of queries
>> users could do.  It also effectively serialises the queries, 
>> preventing
>> them from swamping the RUS.
>>
>> Jon.
>
> -- 
> Sven van den Berghe
> Fujitsu Laboratories of Europe
> +44 208 606 4651
>
>
>





More information about the rus-wg mailing list