[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] SPML 2.0 Relationships proposal...
Jeff Bohren wrote: > [JSB] I'm not going to word smith this document much. It's just a > >proposal. The real word smithing will be done to the actual spec, after >we decide on the technical details. > > "Wordsmithing", huh? If you had to explain this when we were reviewing the document, it probably deserves a sentence, don't you think? Same reply to all "wordsmithing" issues: 3, 6, etc. >5) Along the same lines as the previous comment, I'd suggest that we >rename the 'move' operation to 'setParent' or 'setContainer'. (I know >that 'move' means 're-parent' in LDAP-land, but I'd prefer to make this >more explicit.) Of course, "spmlcontain:SetParentRequestType" could >still extend "spml:BatchableRequestType". > >[JSB] I'm not concerned too much about what we call this, however >"re-parent" would be inappropriate as it could be called on a PSO that >does not already have an explicitly defined parent. > > I did not suggest calling it "re-parent". I suggested calling it 'setParent', which would make sense whether or not the target PSO already has a parent. >9) I think you forgot a field: "Connection Type". You could call this > >"Relationship Type", but it's the same idea. Several connections, each >of a different type, may connect any two objects. Each connection type >in essence defines a separate namespace. (Without this, a request to >delete or modify a connection might remove or update the wrong >connection.) > >[JSB] The Reference ID is the "Connection Type". For instance if a user >is a member of two groups and owns a PDA, there references might be: > >1: refID=memberOf, referentID=group1 >2: refID=memberOf, referentID=group2 >3: refID=owns, refentID=PDA12 > > > Perhaps this needs a little "wordsmithing". I certainly didn't understand this from your write-up. >10) I really wish there were some way to avoid making the (optional) >relationship object a PSO (and giving it an ID). As we discussed at >Long Island, persistently storing these objects (and mapping each to the > >appropriate target object or API) creates scale problems for a >provider. Experience suggests that the number of connections may be an >order of magnitude or more greater than the number of objects connected. > >Rather than identifying a complex connection by an ID, could we specify >a complex connection instance by its From ID, To ID, and Connection >Type? If a provider can map these identifiers to the appropriate target > >object or API, then we avoid persistently storing each complex >connection object as a PSO (and continually having to map its ID). > >In the case of the RACF, these arguments map cleanly to the API. In the > >case of a directory object, it might be necessary to find the connection > >object by starting at one end (either source or target) or by searching >for an object that connects both the "fromID" and the "toID". > >As a consequence, one would modify connection attributes by passing any >object representing a complex connection as part of the 'connect' >request. A single 'connect' verb could implicitly modify any existing >connection between the specified "from" and "to" objects (as it does in >RACF), or we could define separate verbs to "addConnection" and >"modifyConnection". > >Do you see any problems with this kind of approach? Is it possible to >avoid representing each complex connection object as a PSO? > >[JSB] It is possible if the following restrictions are made: >1) There can not be two references with the same "from" and "two" IDs >but with different attributes. > > I think your first restriction should be reworded to: 1) There can not be two references _of_the_same_type_ with the same "from" and "to" IDs. or 1) There can be at most one reference of a given type between two objects A and B. >2) The attributes are always updated as a set. In other words one RA can >not try to set the "admin" attribute on the same relationship while >another is trying to set the "audited" attribute on the same >relationships. > > I do not understand why the attributes would have to be updated as a set. In RACF-land, it is entirely appropriate for one caller to modify the "SPECIAL" flag on a connection while another caller modifies the "OPERATOR" flag on the same connection. In LDAP-land, can't one caller modify an attribute of a name while another caller modifies another attribute of the same name? Can't a modification request specify the element or attribute it intends to add, replace, or delete? I think I may know the source of our "disconnect". You proposed adding state to connections by adding a level of indirection. What you called the "Reference Attributes ID" is a reference to another object that represents any "extra information" stored on the connection. In your proposal, that object is stored persistently as a PSO and is specified by a PSO ID. I like the idea of having an object that represents the "extra information" stored on the connection, but I'm trying to avoid storing (and modifying) that object as a PSO (for the reasons of performance and scale we discussed at Long Island). 1) If a connection object were passed as an optional argument to the 'connect' request, then the connection object could be arbitrarily complex. 2) A connection object passed into a 'connect' request could also be used to update an existing connection: any specified element or attribute would overwrite the corresponding element or attribute of the existing connection (as it does in RACF). On the other hand, it might be cleaner to have a separate operation to modify connections. A 'modifyConnection' request could either replace the entire connection object or could add, replace, or delete specific elements or attributes of the connection object. I don't care much how we do this, as long as there is a way to do it. The big point is that a connection object (and modifications to a connection object) can be mapped to an appropriate target object or API *without* having to store and identify the connection object persistently. Knowing the connection type, from id and to id is enough. This keeps the ID namespace and PSO storage requirements an order of magnitude (or more) smaller. >I think trying to avoid making the attributes a PSO is going to cause >more effort on the implementers than it is going to save. > > You may be right, but I don't see it yet. I'm kinda slow that way. What additional efforts do you foresee? >11) Same as (9): need "Connection Type" in order to uniquely specify an >connection (instance). >[JSB] I don't understand this one. > > You explained above that you intended ReferenceID to be what I call "Connection Type". (I should have explained that the same comment that I made for the Add Request should also apply to the Modify Request.) Gary
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]