- **Milestone**: 4.6.FC --> future
- **Comment**:
Ticket #643 (IMM: API that replaces SaNameT with SaStringT and
SA_IMM_ATTR_DN) also removes the need for imm api users/programers to
have to deal with the awkward concept of the RDN-attribute and the
RDN-attribute-value or the RDN-value. The RDN of an object is a component
of that objects DN. For a root object, the RDN equals the DN. Both the
DN and the RDN are values.
For some reason, SAF specified that the RDN should be redundantly represented
also in an attribute of the object.
Since the value of that attribute is a redundant value, we dont really
need that attribute. Neither physically or logically.
The new SaStringT based API provided by ticket #643 also alters the
parameter behavior for some API calls. The new downcalls for
saImmOmCcbObjectCreate and saImmOiRtObjectCreate do not take any RDN
value as part of the attribute-values. Instead thy get the RDN by having
the parent-dn parameter replaced by the object-dn parameter.
The new version of the callback SaImmOiCcbObjectCreateCallbackT will not
provide any RDN attribute in the lists of attributes provided to the OI,
since the OI does not need it to create the object DN and if the OI needs
the RDN for other purposes it can just obtain it from the provided DN.
In additon the attribute values returned in the new version of the
saImmOmSearchNext or saImmOmAccessorGet will by default NOT include
the RDN attribute. Only if the client explicitly asks for the RDN attribute
by adding it to the attributeNames parameter in saImmOmSearchInitialize or
saImmOmAccessorGet, will the RDN attribute be returned.
This ticket addresses another issue. Whenever the RDN attribute is
returned, whether in the old API or the new, there has been debate on
whether the value of the RDN attribute should simply be the RDNs value or
if it should be the value of the right hand side of the X=Y format
for the value that the RDN normally has.
Current behavior for the OpenSAF imm has always been to return the complete
RDN as the RDN attribute value. But the intention of the SAF IMM specification
has apparently always been that the value returned for the
RDN attribute should be only the right hand side of the value that is the
RDN. The value that is the RDN is normally expressed as X=Y where X is
a redundant copy of the attribute name (redundant since it is defined in
the imm class) and Y is the "RDN value", not to be confused with the value
that is the RDN.
All of this confusion and redundancy disaperas with the new SaStringT API yet
we also want to support applications that expect the "short format"
for hte RDN value.
The proposal is to introduce a new library environment variable named
SA_IMM_RDN_RHS to stand for "RDN Right Hand Side". IF this environment variable
is set, then the IMM API for all versions, for the release that
implements this ticket, will return the right hand side value of the RDN
wnenever the RDN attribute is returned.
It will also expect the RDN attribute to only contain the righjt hand
side when assigned as input parameter to the ccb-create and rt-create APIs.
---
** [tickets:#38] IMM: Make RDN attribute values virtual**
**Status:** assigned
**Milestone:** future
**Created:** Tue May 07, 2013 11:26 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue Dec 30, 2014 11:44 AM UTC
**Owner:** Zoran Milinkovic
The objectCreate APIs (both config and runtime) will be simplified as part
of the new SaStringT based API (#643).
What remains for this ticket is the "virtualization" of the RDN attribute.
This consists of:
1) By default not returning the RDN attribute as part of a search or
accessorGet.
The RDN attribute would only be fetched if explicitly asked for, by including
the attribute-name in the 'attributeNames' parameter.
The RDN attribute is only needed when the old object-create APIs are used,
where the parent-dn is provided and the user has to provide the RDN
explicitly.
For all other cases, where the object DN is used (as input or in output),
the RDN is alsready provided/received as part of the DN.
Migrated from:
http://devel.opensaf.org/ticket/3081
-----------------------------------------------------------------------
Anyone that has tried to program using the IMM APIs will have
discover that they are quite cumbersome to use. The immutils
library may help a bit. But one issue in particular has bothered
me a lot, almost as much as the SaNameT type or the concept of
persistent runtime data. It is the concept of the RDN attribute
and the way the object create APIs are forced to deal with it.
First the concept itself is strange since the RDN attribute value
is totally redundant. The RDN (Relative Distinguished Name) has to
be maintained anyway as part of the DN for an object. So why
bother maintaining a redundant copy of part of the DN as an
attribute value ?
As far as I can understand, no application actually wants or needs
to fetch the RDN attribute value. If it knows the DN
for an object, then it trivially already has the RDN for the
objects so it should never need fetch it the RDN attribute value.
Redundancy in data structures is typically bad since it invites
discrepancy/inconsistency. In the case of the RDN attribute we
even have the risk of discrepancy at the logical/spec level.
Should the RDN attribute contain the full RDN or half of the RDN?
The full RDN is the RDN (Relative Distinguished Name) for the
object. No doubt about what that is. It is everything up to the
first non escaped comma scanning the DN from left to right.
But should the RDN attribute contain the RDN? Complicating the
issue is that not only is the RDN attribute value redundant, in
addition SAF has the convention of defining RDN's so that they
redundantly contain the RDN attribute name as part of the RDN.
This is redundant because the given the class we can find the RDN
attribute name (assuming there was a reason to be interested in the
RDN attribute name .. and I dont actually know any reason for
anyone to be intereseted in it at the instance level).
The SAF IMM RDN convention is inspired from LDAP. Inspired is the
right word here and not 'adopted' as standard. LDAP does not have
the concept of class and thus not the concept of attributes of a
class and most importantly not the concept of an RDN attribute.
So the RDN attribute convention in SAF is not simply the adoption
of a part of the LDAP standard because the imm data model departs
significantly from LDAP.
LDAP has "attribute types" instead of classes and that explains why
the attribute-type-name used in an LDAP RDN has to be part of the
RDN in LDAP. But the same is not true for the imm service.
Some say that the in the Imm, the RDN attribute value is not the
same as the RDN. It is "half" of the RDN, i.e. that part of the
RDN that is not redundant at the type level, but still redundant
at the instance/object level.For historical reasons the OpenSAF
implementation of IMM stores the complete RDN value as the
RDN attribute value.
This ticket proposes to make the issue moot by defining the RDN
attribute value as a "virtual" attribute value. That is the RDN
attribute value would not need to be provided when creating an
imm object. Instead the RDN attribute value would be reconstructed
on-demand, i.e. when fetched. By default, the RDN attribute value
would be reconstructed as the complete RDN value. But users that
prefer to see only half of the RDN as the RDN attribute value
could set an IMMA config parameter to get this behavior.
New versions of the object create APIs and callbacks would be
provided that avoid dealing with the RDN attribute, since it is
redundant and complicates the API usage.
/* 4.8.2 saImmOmCcbObjectCreate() Existing signature */
extern SaAisErrorT
saImmOmCcbObjectCreate_2(SaImmCcbHandleT ccbHandle,
const SaImmClassNameT className, const SaNameT *parentName,
const SaImmAttrValuesT_2 **attrValues);
/* saImmOmCcbObjectCreate() new signature */
extern SaAisErrorT
saImmOmCcbObjectCreate_o2(SaImmCcbHandleT ccbHandle,
const SaImmClassNameT className, const SaNameT *objectName,
const SaImmAttrValuesT_2 **attrValues);
Added semantics: RDN attribute need not be included in the
attrValues list. If it is included, a check is made that it
matches *either* the complete RDN or half of the RDN.
If it is included but matches neither then INVALID_PARAM is
returned.
---------------------------------------------------------------------
/* 5.6.1 SaImmOiCcbObjectCreateCallback? existing signature */
typedef SaAisErrorT
(*SaImmOiCcbObjectCreateCallbackT_2) (SaImmOiHandleT immOiHandle,
SaImmOiCcbIdT ccbId, const SaImmClassNameT className,
const SaNameT *parentName, const SaImmAttrValuesT_2 **attr);
/* SaImmOiCcbObjectCreateCallbackT new signature */
typedef SaAisErrorT
(*SaImmOiCcbObjectCreateCallbackT_o2) (SaImmOiHandleT immOiHandle,
SaImmOiCcbIdT ccbId, const SaImmClassNameT className,
const SaNameT *objectName, const SaImmAttrValuesT_2 **attr);
Added semantics: RDN attribute is not included in the attr list.
It is no longer needed by the OI since the only reason the OI
needed it in the old signature is to re-construct the DN.
With this new callback, the OI is instead served the DN for the
new objecte directly. Much simpler and much better.
---------------------------------------------------------------
/* 5.5.1 saImmOiRtObjectCreate() old signature */
extern SaAisErrorT
saImmOiRtObjectCreate_2(SaImmOiHandleT immOiHandle,
const SaImmClassNameT className, const SaNameT *parentName,
const SaImmAttrValuesT_2 **attrValues);
/* saImmOiRtObjectCreate() new signature */
extern SaAisErrorT
saImmOiRtObjectCreate_o2(SaImmOiHandleT immOiHandle,
const SaImmClassNameT className, const SaNameT *objectName,
const SaImmAttrValuesT_2 **attrValues);
Added semantics: RDN attribute need not be included in the
attrValues list. If it is included, a check is made that it
matches *either* the complete RDN or half of the RDN.
If it is included but matches neither then INVALID_PARAM is
returned.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
