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

[Rob Crittenden]

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.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20091022/ac69704a/attachment.bin>