[graap-wg] minutes from 2/28 telecon

[Jon MacLaren]

I'll try and explain my original concern, although I'm pretty certain 
after reading your mail that it is actually of no concern.

I was worried that someone could read the RP document while it was 
half-way through being written.  I was thinking in terms of a chunk of 
memory being written by one thread, as another tries a read.  But from 
what you say, i.e. that the results will be valid according to the 
schema, this is clearly not an issue.

Given that updates to the component parts of an RP are atomic in some 
sense, I'm not aware of any coherence issues in the current 
WS-Agreement spec.  Which is I guess what the comment from the telecon 
was saying also.

Thanks for the clarification...

Jon.


On Mar 1, 2005, at 8:51 AM, Karl Czajkowski wrote:

> I am not sure that I am following this concern, but to my knowledge
> WS-ResourceProperties does not define any coherency or consistency
> among resource properties.  It only states that query results will be
> valid according to the schema.  This is not about "writers" but about
> dynamic RP documents and the possible lack of synchronization in
> constructing the RP elements in query results.  (WS-RF tries to be
> lenient about what infrastructure is required to implement the basic
> facilities.)
>
> I think the best approach would be to define RPs that are meaningful
> in isolation from one another and only loosely associated with each
> other via their association to the resource identity; dynamic values
> that have temporal associations should probably be part of one RP
> element rather than spread across several.  I do not think there is
> anything risky about stating that a particular RP will be updated
> coherently (coherence amongs its attributes and subelements).
>
> A particular specification could add requirements, but of course this
> might restrict the WSRF tooling environments that are capable of
> hosting the standard.  Also, I would be concerned if we required
> strong consistency and didn't make it so that a WS-Agreement
> environment would degrade gracefully if the consistency were violated;
> for example, references across terms could use temporally unique IDs
> for dynamic elements so that a consumer could detect a dangling
> reference rather than making an incorrect dereference.  I suppose you
> could call this an implementation detail, but I would like to think we
> could encourage or even mandate some hygiene...
>
> Can someone explain concisely what the consistency hazard is that has
> been raised?
>
>
> karl
>
>
> On Feb 28, Jon MacLaren loaded a tape reading:
>>> Issue 13: The only thing that can change is the term states because
>>> there is no updates.  So, there is no concern for consistency, and no
>>> need for consistent updates.  **Action: Respond that we don't think
>>> this is a concern in the follow up.  **Jim will add the comment to 
>>> the
>>> tracker.
>>
>> Just to clarify...  I realise that no external parties able to update
>> the monitoring information.  However, the service/resource is changing
>> state - is this state change any different from an external writer?  I
>> wasn't sure that WS-RF would guarantee the user sees a consistent 
>> state
>> at these times - I thought you only needed one writer and one reader
>> for consistency problems here.
>>
>> Maybe someone who knows WS-RF better than me can clarify this.
>>
>> Jon.
>
> -- 
> Karl Czajkowski
> karlcz at univa.com
>