[Freeipa-devel] validating return values in XML-RPC

[Dmitri Pal]

Rob Crittenden wrote:
> John Dennis wrote:
>> On 10/22/2009 10:45 AM, Jason Gerard DeRose wrote:
>>> So I've been thinking about this as I've been doing the UI
>>> "tuning" (extending meta-data and making the engine smarter).  I agree
>>> with John that we need to describe the return values programatically.
>>> We can also kill two birds with one stone here because the description
>>> of the return values is a great way to provide some of the meta-data
>>> the
>>> UI needs (and the CLI... there is something in place now, but it's not
>>> easily plugable).
>>>
>>> I personally feel the design of the Param system has held up pretty
>>> well
>>> (Rob and Pavel, speak now or forever hold your peace), so I think we
>>> should use the Param classes to describe the return values.  This will
>>> really help us reduce code duplication and allow for good plugability
>>> because, as usual, most of our commands are CRUD operations, so we can
>>> generally use some auto-magic to deduce the return values from the
>>> corresponding Object params.
>>>
>>> Thoughts?
>>
>> If you're asking if the description of the return values should be
>> expressed using the same Param classes as the input values then yes I
>> agree. I had pretty much expected we would reuse the Param
>> declarations for the return values.
>>
>> However if you're asking should the description of the return values
>> be magically deduced from the input parameters then no I don't agree,
>> I think both the input and output parameters should be explicitly
>> declared so a programmer can look at the code and see what they are
>> just like in any typed language.
>>
>
> I'm not entirely sure this is going to be possible, at least not at
> this level. The attributes returned will not be this predictable. At
> best it could include just some possible attributes returned and some
> vague data type information.
>
> Take the group plugin for an example.
>
> ipa group-show will return something like a string and a dict. The
> string is the DN of the entry and the dict is the list of attributes
> returned. Within the dict are any number of attributes, some of which
> we can define in advance. So we know that a group requires a cn and a
> description, so we can define that. But what about members? That is an
> optional attribute, do we define that? And a group can be a member of
> other groups, so I guess the same would apply. I guess that's fine, we
> can define optional incoming options, we can do outgoing ones in the
> same way.
>
> Ok, now the interesting part. One can also pass --all to the function
> which returns every attribute in the object. What do we do with these
> unexpected attributes? Now imagine a much more complex object and you
> can see how this quickly becomes unmanageable. Once you start allowing
> unknown things to be returned we are in pretty much the same boat we
> are now only with the false impression that we have control.
>
> On the bright side once the output of show gets defined the rest
> becomes a bit easier. add will return the same type of thing (it calls
> show on the newly added object and returns that). find will return a
> list of these things. delete I believe delete just returns the dn of
> the entry deleted, that's easy too.
>
> There are other commands that can return all kinds of other wacky
> stuff, see the env plugin for that.

May be it is a too big of a stretch but the DS has syntaxes in schema so
can we derive data type of the returned value from the syntax of the
unknown attribute?
There should be a pretty simple mapping of DS syntaxes to the return
value types. This way we would be able to handle the specific attributes
we know about in a way we define but would be able to pass back and
process the unknown attributes in a generic way.


>
> rob
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/