Re: [provision] Groups - 2.0-Relationships.pdf uploaded

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Shmuel,

Thank you very much for your suggestions.  I appreciate you contributing 
new ideas to this discussion.  My questions and comments are inline below.

Shmuel Koller wrote:

>Minor requirement point - I think for completness of
>this particular discussion  - SPML search needs also
>to support Retrieval of "connection attributes" in
>addition connect and modify-connection. So we need
>schema attributes for connection once again as per
>Gary concern Third step below.
>  
>
1) I suggested that we do not necessarily need a verb to 
'modify-connection' if the 'connect' verb is understood to modify any 
existing connection between the specified objects.  What is your opinion?

2) I suggested that we _would_ need some kind of schema for a complex 
connectionType (and I asked Doron whether he agreed with that 
assessment).  If am secretly hoping that there is some way to avoid 
having to expose schema for complex connection types, since this adds 
overhead to the implementation, but I do not see how we could do that. 

To be perfectly plain about my bias, I do not want to add support for 
complex relationship types if this complicates support for simple 
relationship types.
 

>The solution is I think between Long Island and
>current discussion. Support Primary Identifier and
>Secondary identifier (order is important, to the  PSP
>implementation).
>
>This will keep SPML simple - as all provisioning basic
>commands will apply to connections, via specification
>of a Pair of Identifiers, also Schema exchange.
>
How would schema exchange apply to identifier pairs?  Are you suggesting 
that a pair of types is also a type, so that {Type1,Type2} could have 
its own schema?

> 
>
>That done - it does not limit the semantics of the
>Identifier Pair to mean "connection" but anything that
>the PSP wishes, and again - the identifier orders
>order can matter or not to the implementation.
>  
>
This is an interesting possibility, but I'm not sure that I find that 
degree of freedom to be attractive.  One of our goals for SPML 2.0 is to 
make the protocol better reflect the domain of provisioning.  I think I 
like the idea of an identifier pair better if an identifier pair 
*always* refers to a connection.

>With SPML 1.0 and its verb "simplicity yet powerful
>for provisioning" - that was a choice - to implement
>the Connection pair of identifier as "string
>concatenation"  
>into one SPML identifier. I think its worth to let
>SPML express an Identifiers Tupple (or at least pair)
>and keep its command set simple - while enriching the
>data model (to FULLY express provisioning of
>connections, but not represent them).
>
>I think the pair of identifiers can be considered as
>much stateless and non-persistent as one identifier -
>for this matter. Its just a "key" for the SPML
>provisioning command. And - at the same time it
>provides full coverage for provisioning connections,
>where (if and only if  implementation wishes so): 
>spmladd(id1,id2) - means connect 
>spmldel(id1,id2) - means disconnect 
>spmlget(id1,null) - as if just id1
>spmlget(id1) - will cascade to delete connection
>(depends on implementation)
>  
>
I think you meant "spmldel(id1) - will cascade to delete connection", right?

Again, I think that this idea is interesting and powerful, but I'm 
concerned that it may be overly abstract.  I think that I prefer to have 
explicit 'connect' and 'disconnect' operations.

We've done a fair amount of work (after a great deal of discussion) to 
separate the verbs proposed for SPML 2.0 into separate core and optional 
interfaces.  This allows each provider (and indeed each target) to 
declare which operations it supports.  This suggestion would take us 
back in the other direction, making it more difficult to determine which 
"flavors" of an operation a provider supports.

>The SPML opportunity here to stay simple and powerfull
>is that ConnctionType is an Attribute of (id1,id2)    
>  
>
I would like to better understand this suggestion.  I can imagine that a 
connectionType might be represented as an attribute of (Type1,Type2) in 
the schema, but  I  do not see how a connection *type* could be an 
attribute of two *instances*.  That's probably not what you meant.  What 
did you mean?

Thanks,

Gary