- **summary**: IMM: Simplify object-create APIs and make RDN attribute values
virtual --> IMM: Make RDN attribute values virtual
- Description has changed:
Diff:
~~~~
--- old
+++ new
@@ -1,3 +1,20 @@
+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
-----------------------------------------------------------------------
~~~~
---
** [tickets:#38] IMM: Make RDN attribute values virtual**
**Status:** unassigned
**Milestone:** future
**Created:** Tue May 07, 2013 11:26 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue Sep 09, 2014 06:23 PM UTC
**Owner:** Anders Bjornerstedt
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.------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
