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 > Freeipafirstname.lastname@example.org > 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/ _______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel