Good.
I hope to also provide a first version of an SaStringT based IMM API
(#643 https://sourceforge.net/p/opensaf/tickets/643)
for review quite soon (as soon as we finish 4.4.0). This will be
provided as incremental include files saImmOm_A_2_14.h
and saImmOi_A_2_14.h and be available ofr imm handles initialized with
A.2.14
If and when that is approved in OpenSAF, then providing an
implementation should not be too difficult.
/AndersBj
Anders Widell wrote:
> I have re-based this patch so that it applies on OpenSAF 4.4.RC1. In
> addition, this new version contains (yet untested) modifications to NTF and
> SMF, to get a feeling for how difficult it is to adapt these services for
> long DNs.
>
>
> Attachment: long_dn_prototype_v2.diff (232.3 kB; text/x-patch)
>
>
> ---
>
> ** [tickets:#191] IMM: SaNameT 256 byte size limit and RDN 64 byte size
> limit.**
>
> **Status:** accepted
> **Created:** Tue May 14, 2013 08:12 AM UTC by Anders Bjornerstedt
> **Last Updated:** Tue Dec 03, 2013 02:35 PM UTC
> **Owner:** Anders Widell
>
> The SaNameT type and in particular its limit in size of 256 bytes
> is an aspect of the SAF standard that was, shall we say, not so
> well conceived.
>
> The 256 byte limit on SaNameT implies the same limit on DN length.
> it is also the reason behind the 64 byte limit on RDN length, if the
> RDN attribute is defined on SaStringT.
>
> The SaNameT type is used more or less in the APIs of practically all
> SAF services. Thus an enhancement that would try to extend it
> length would not just be an enhancement on the IMM service,
> but all services.
>
> This discussion topic is intended to probe the possibility of
> increasing the size of SaNameT, or of replacing SaNameT with
> a type defined in the same way as SaStringT.
> There is still a point in having a DN type, that is semantically
> distinct from SaStringT, because a DN is in essence the IMM
> reference data-type.
>
> One possibility is to continue with SaNameT, but extend both
> its struct definition and the size limit.
> The "length" member is already defined as SaUint?16T,
> which means the length member is not the problem.
>
> Had the SAF standard been defined in C++ we could just create
> a subclass to the SaNameT class, but since we are restricted to
> the more primitive C language, one has to either create a
> completely new type SaNameT_2 or do some kind of "trick".
>
> Changing the type has the big problem that it impacts so many
> APIs and in a non backwards compatible way.
>
> So I propose some form of trick.
>
> For example, we can exploit the 16 bit size field, in a way that
> is both backwards compatible and forwards compatible.
>
> Assume that if the high order bit of the length feild is set,
> then it indicates that this is an extended SaNameT type.
>
> In this case, the value member will not contain the
> plain string. Instead it contains first a null terminated
> marker string such as "Long SaNameT..." (16 bytes long
> including the null termination).
>
> After this string there will be stored a pointer,
> which should be aligned on 64/32 bit architectures.
> That pointer is a pointer to char*, i.e. it is supposed
> to be a pointer to a null terminated string.
>
> The actual size of the string would not be stored in the length
> field. For one, it is not needed since we have a null
> terminated string. For another, it is prudent not to use the
> length field, except the high order bit, to guard against
> bugs and illegal use.
>
> This is backwards compatible in the sense that any old API
> that currently accepts SaNameT, but that has not been migrated
> to a version that understands the extended SaNameT, should
> reject the value as being too large. That is it should at least
> not just crash. The token string is also there so that naiive
> code that ignores the length field and just assumes a null
> terminated string in the old SaNameT value array, will find
> such a string. Again, it should not crash uncontrollably but
> at worst behave in a way that is not correct, but is quickly
> recognizable as to its cause.
> That "Long SaNameT..." string will be visible and recognizable
> for what it is and the bug in the old code can be fixed.
>
> Once an extended SaNameT type is supported in the the immsv,
> there is no reason to keep the 64 byte limit on RDN length.
>
>
>
>
> ---
>
> Sent from sourceforge.net because you indicated interest in
> <https://sourceforge.net/p/opensaf/tickets/191/>
>
> To unsubscribe from further messages, please visit
> <https://sourceforge.net/auth/subscriptions/>
>
---
** [tickets:#191] IMM: SaNameT 256 byte size limit and RDN 64 byte size limit.**
**Status:** accepted
**Created:** Tue May 14, 2013 08:12 AM UTC by Anders Bjornerstedt
**Last Updated:** Fri Feb 07, 2014 10:43 AM UTC
**Owner:** Anders Widell
The SaNameT type and in particular its limit in size of 256 bytes
is an aspect of the SAF standard that was, shall we say, not so
well conceived.
The 256 byte limit on SaNameT implies the same limit on DN length.
it is also the reason behind the 64 byte limit on RDN length, if the
RDN attribute is defined on SaStringT.
The SaNameT type is used more or less in the APIs of practically all
SAF services. Thus an enhancement that would try to extend it
length would not just be an enhancement on the IMM service,
but all services.
This discussion topic is intended to probe the possibility of
increasing the size of SaNameT, or of replacing SaNameT with
a type defined in the same way as SaStringT.
There is still a point in having a DN type, that is semantically
distinct from SaStringT, because a DN is in essence the IMM
reference data-type.
One possibility is to continue with SaNameT, but extend both
its struct definition and the size limit.
The "length" member is already defined as SaUint?16T,
which means the length member is not the problem.
Had the SAF standard been defined in C++ we could just create
a subclass to the SaNameT class, but since we are restricted to
the more primitive C language, one has to either create a
completely new type SaNameT_2 or do some kind of "trick".
Changing the type has the big problem that it impacts so many
APIs and in a non backwards compatible way.
So I propose some form of trick.
For example, we can exploit the 16 bit size field, in a way that
is both backwards compatible and forwards compatible.
Assume that if the high order bit of the length feild is set,
then it indicates that this is an extended SaNameT type.
In this case, the value member will not contain the
plain string. Instead it contains first a null terminated
marker string such as "Long SaNameT..." (16 bytes long
including the null termination).
After this string there will be stored a pointer,
which should be aligned on 64/32 bit architectures.
That pointer is a pointer to char*, i.e. it is supposed
to be a pointer to a null terminated string.
The actual size of the string would not be stored in the length
field. For one, it is not needed since we have a null
terminated string. For another, it is prudent not to use the
length field, except the high order bit, to guard against
bugs and illegal use.
This is backwards compatible in the sense that any old API
that currently accepts SaNameT, but that has not been migrated
to a version that understands the extended SaNameT, should
reject the value as being too large. That is it should at least
not just crash. The token string is also there so that naiive
code that ignores the length field and just assumes a null
terminated string in the old SaNameT value array, will find
such a string. Again, it should not crash uncontrollably but
at worst behave in a way that is not correct, but is quickly
recognizable as to its cause.
That "Long SaNameT..." string will be visible and recognizable
for what it is and the bug in the old code can be fixed.
Once an extended SaNameT type is supported in the the immsv,
there is no reason to keep the 64 byte limit on RDN length.
---
Sent from sourceforge.net because [email protected] is
subscribed to http://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
http://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
