Re[2]: [higgins-dev] IdAS update proposals

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

Jim,

See in-line.

-- 
Thanks,

Valery

Monday, April 16, 2007, 7:15:27 PM, you wrote:

>  


>>>> Jim Sermersheim 4/16/07 10:10 AM >>>
>  
>>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/15/07 5:12 PM >>>
>>Right now I'd prefer option 3 because I'm a little bit confused with
>>the option 3.a. However I have to notice that if we introduce
>>transactional support like IContext.commit() we should also provide a
>>way like IContext.rollback() to restore local context state if
>>transaction fails for some reason.
>  
> IContext.commit("Atomic") does just this.  The semantics are that
> if the transaction fails for some reason, all changes are rolled back (not committed).
>
But the local state of the context remains changed. In general I see
two cases why some transaction may fails - one due to device failure
and another due to invalid data in the local state of the context. In
the first case a consumer may choose just to commit again while in the
second it is much easier to restore context local state and start to
update it again then to find out and resolve real reason of the
failure. That is why I think we need a method like rollback().

>>With regards to option 3a I have two point of confusion.
>>My first point of confusion is proposed semantic of add*
>>methods. The description of IDigitalSubject.addAttribute method says
>>that when null is passed as attr parameter, "the digital subject
>>returns an empty IAttribute (one with no values)". My question is which
>>type of attribute will be returned if digital subject could contains
>>two types?
>  
> I think I see what you're asking.  My intent was that it would
> return an IAttribute instance which had neither a type, nor any
> values.  We could optionally or also make addAttribute take a type
> argument so that the returned IAttribute has a type associated with it.
>
As for me an IAttribute which has neither a type, nor any values is
useless because in this case we don't have any way to find out what
values it could contains at all.

What we could is to define two methods:

IAttribute addAttribute(URI type, ...);
IAttribute addAttribute(IAttribute attr, ...);

In this case the first method will create, add and return newly added
IAttribute while the second will create, add, make a deep copy of attr
parameter and returns newly added IAttribute.

>>My second point of confusion with option 3a is proposed
>>TransactionSemantics parameter. My question is what will happens when
>>first we call few methods with the semantic parameter set to
>>"OnCommit" and then we call another method with the semantic parameter
>>set to "Immediate"?
>  
> All updates which set it to "OnCommit" are held by the CP until
> IContext.commit is called.  All updates which set it to "Immediate"
> are committed immediately.  So, yes, you could mix these calls if you wanted.
>
I'd prefer not to mix them because it may leads to a hardly resolvable
situations when my waiting updates become invalid after a single call
to "immediate" method.

>>I'm thinking about option 3x where we rather refactor then remove
>>build methods.
>  
> That what I intended with 3.a "... we remove the build* methods..."
>
In this case each particular substance in the context
(i.e. IDigitalSubject, IAttribute, IProperty, IMetadata, etc.) must
know exact type of values it could/should create but it seems
impossible in the situation when an IAttribute, for example, has
neither a type nor any values.

>>With regards to use cases I think we need to split use case 1 (add new
>>subject). One is when the type of digital subject is know (i.e. we
>>know what types of attributes could be added to the subject) and another
>>when the type of digital subject is unknown.
>  
> Yes, let's do this.  I'm pretending not to work until this
> afternoon, I'll update the page then.
>  
>  
>  
>  
>  
> Jim

>