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?
