[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] SPML 2.0 Relationships proposal...
Jeff, I haven't seen your reply in this thread (I saw your reply to Gerry). Some of my points were unimportant, but I think #10 is worth addressing. Gary P Cole wrote: > Jeff Bohren wrote: > > Gary Cole wrote: > >> 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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]