|
Some of my attributes for Set are of a complicated constructed
type, like a SetOf Records, with record members being Sets in their
turn.
>
> Nesting of ILV constructions can't exceed 12 levels deep, and this limit
> can't change easily. This 12 includes 1 level for the PUT_PARAM_BEGIN, and
> another 2 for a primitive value encoded in an attrib_list (3 for a one-level
> construction in an attrib_list). This is only a DEPTH of nesting limit.
> You may have up to 32500 bytes of ILV encoding. This limit may change,
> and will change if it proves too small. A gross estimate of overhead:
> 4 bytes per primitive value + 4 bytes per put_cons_begin-put_cons_end pair.
>
Because of this, the ILV decoding from in_p, and encoding for out_p
inside the AM for a Set directive uses a lot of code.
Ideally, I could avoid the encoding for out_p by just copying
the corresponding attribute from the in_p context to the out_p
context, using the mcc_ilv_copy_param routine.
However, this doesn't work if AM wants to return an error reason
code with the attribute.
So, I have the following questions:
1. If I am encoding the constructed attribute into out_p context
with an error reason, is there some way to avoid encoding
back the entire complex constructed attribute decoded from
the in_p? It seems, that for error reason codes the actual
attribute Value should not matter anyway, so it could be
something very simple (or Null).
>
>We define any attribute value accompanied by any non-success reason code
>invalid, and ignore it. Section 9.4.10 (attrib_list) of the SRM v1.1 says
>that for any reason code other than success, the reason and NOT the value is
>displayed. So, encode a null for the value.
>
>For fixed length primitive datatypes, this is non-trivial, as there isn't
>a null or "no-value" value defined
>for most of them. In this case, you have to rely on the protocol and
>ignore the value, and for encoding purposes, return the value that failed.
>(you presumably have that value handy!)
>For datatypes that allow a 0 length value, supply 0 as a length in the
>mcc descriptor's mcc_w_curlen field.
>For constructor/ed types, a put_cons_begin followed immediately by a
>put_cons_end is a null. The SRM (v1.1) either does or ought to supply
>enough information to do this in ch 9.
2. Can mcc_ilv_get call be used to read the entire constructed
value, right after mcc_ilv_get_id for the construction, and
without reading it via multiple primitive gets via
mcc_ilv_get_cons_begin, etc.? If Yes, what should be in the
mcc_l_dt in the Descriptor argument to the mcc_ilv_get call?
The SRM is not clear on this one.
>Since you say the SRM is not clear, I am not quite sure what you're
>looking for. ILV_GET will decode and return in one call all
>"primitive" datatypes, and AES'es (FULL or LOCAL ENTITY NAME datatypes).
>If you constructed it yourself, you have to deconstruct it yourself.
>Except for the AES'es, all constructor and constructed datatypes are
>hand-done right now.
>The datatype in the mcc_l_dt field of the mcc descriptor for an ILV_GET value
>must match the datatype encoded with the data, except in one case:
> Implementation Default.
>You either hardcode the datatype expected when you decode something,
>or you can be data-driven and look it up in the dictionary.
> In the Implementation Default case, no value was encoded (each
>implementation is expected to know its default), the Implementation
>default flag is set in the mcc_b_flags field of the descriptor, and you get the
>IMPLDEFAULT CVR. See the ILV_PUT and ILV_GET routine descriptions in
>the v1.1 SRM.
3. Is there a routine which copies the ILV attribute from
one context to the next, but with a caller supplied new
reason?
>No. However, I encourage you to make your own common routines,
>and to share them (with appropriate caveats). I also encourage
>you to "share" any common routines you make that you find useful with us.
>I am not sure what form such sharing should take--this notes file is
>taken seriously, but is probably too informal a mechanism.
> I hope this is more than you wanted to know, but covers what you need!
Ruth
|
| >>>
>>> 2. Can mcc_ilv_get call be used to read the entire constructed
>>> value, right after mcc_ilv_get_id for the construction, and
>>> without reading it via multiple primitive gets via
>>> mcc_ilv_get_cons_begin, etc.? If Yes, what should be in the
>>> mcc_l_dt in the Descriptor argument to the mcc_ilv_get call?
>>>
>>> The SRM is not clear on this one.
>>>
>>> >Since you say the SRM is not clear, I am not quite sure what you're
>>> >looking for. ILV_GET will decode and return in one call all
>>> >"primitive" datatypes, and AES'es (FULL or LOCAL ENTITY NAME datatypes).
>>> >If you constructed it yourself, you have to deconstruct it yourself.
>>> >Except for the AES'es, all constructor and constructed datatypes are
>>> >hand-done right now.
Ruth,
I believe he was asking whether ILV_GET can decode and return in one all
all "constructor" datatypes. For example, if he had a record where one
of the fields in the record is a SETOF datatype, can he get the entire
SETOF construction in one ILV_GET, rather than having to decode the
entire SETOF element-by-element, using GET_CONS_BEGIN and then GETs.
Christine
|
|
Christine,
The answer is the same :
With the *current* ILV routines--
If it was constructed piece by piece, it must be read piece by piece.
Pieces can be copied at the id'd constructor level (e.g. by a whole SET),
but not encoded or decoded that way (the set must be read element by element,
and if those are complex, they must be opened and decoded, etc., the
reverse of the construction of the SET). Remember, the ilv_get and _put
routines deal with one mcc_descriptor's worth of data per call.
Except for the AES'es, all constructor and constructed datatypes are
encoded and decoded using _put_ and _get_cons_begin, and _put and _get.
I doubt very much the set of ILV routines will be expanded.
Sorry,
Ruth
|