Michael DeHaan wrote:
Steve Milner wrote:
I'd like to re-open the talk about how modules return data. I
personally like the idea of a response object that __str__ returns the
exact data that the command returned (or function decides on) along
with other methods to get data in helpful ways (get_lines(),
get_first_line(), etc..).
Thoughts? Ideas? Insane responses?
Modules shouldn't be thinking in terms of "lines of output" IMHO. If
we do that, we aren't too much better than 'expect' based solutions.
We should be thinking in terms of data, where as the nested hash
results seem to serve us well. Of course, 'standardization' of
return data is rather complex in it's own right, whether or not there
is a happy object to encapsulate it.
Adrian had some good suggestions about creating some higher level
client side APIs for doing more advanced things,
which seems to make sense there.
Anyhow, I have a preference towards seeing things not becoming all
based on parsing, and moving towards programatic ways of returning the
same data where we can.
I read this wrong... my fault.
For the list, btw, Adrian pointed out that capturing all output for
auditing would be great. This is true.
Take a crack at it... if something can be done that keeps the existing
script calling convention working working, that might be interesting?
I still think another Func hackfest is in order in a week or two to
scheme schemes and plan what we might be building on top of this.
Maybe sooner even.
We had some return objects in virt factory's RPC that I didn't like,
though maybe this can be done in a cleaner way.
--Michael
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
