Re: [Qemu-devel] [PATCH v0 00/10]: More QObject conversions

[Markus Armbruster]

Luiz Capitulino <address@hidden> writes:

> On Sat, 10 Oct 2009 14:31:12 +0200
> Markus Armbruster <address@hidden> wrote:
>
>> Luiz Capitulino <address@hidden> writes:
>> 
>> >  Hi there,
>> >
>> >  Here goes another set of conversions, just to keep the ball rolling.
>> >
>> >  The first patch introduces a function called qobject_from_fmt(), which can
>> > be used to build QObjects from a specified printf-like format.
>> >
>> >  Most of its code was based on a Python function with similiar 
>> > functionality,
>> > as far as I could understand the license is compatible and I've added a
>> > copyright notice.
>> >
>> >  Is this the right procedure?
>> >
>> >  Most patches are simple (as we aren't converting errors yet), except the
>> > last ones. Which use qobject_from_fmt() and are very cool, hopefully 
>> > they're
>> > right too. :)
>> >
>> > PS: This series apply on top of my last 'Initial QObject conversion' 
>> > series.
>> >
>> >  Thanks.
>> 
>> The separation of presentation from logic seems to work reasonably well
>> so far.  The separation involves building explicit data to be sent by a
>> separate presentation function instead of printing right away.  It's key
>> that this data building code is about as legible and easy to maintain as
>> the old, straightforward printing.  qobject_from_fmt() helps with that,
>> in my opinion.
>
>  Yes, it helps, although adding more abstraction layers usually makes
> things more complex.. That is, this is never going to be as simple as
> directly calling monitor_printf().
>
>> Of course, much "interesting" stuff remains, chiefly errors.
>
>  Yes, and errors are more complicated than regular output because
> sometimes we have something like:
>
> command_handler()
>  func1()
>   func2()
>    func3() <--- calls monitor_printf() on error

Additionally, the fact that we failed is propagated up the call chain
some.  Ideally all the way up to command_handler().  Tedious, but
typically unavoidable, because upper functions need to be stopped from
continuing after failure.

>  Also, an error condition has to be differently handled from regular
> output, so that the protocol can emit it as an error.

It's a different kind of response, but it is built in similar ways.

A command sends either a normal response or an error response.  Both are
objects.

command_handler() builds a normal response object, possibly
incrementally, possibly delegating part of the job to other functions.
You use parameter passing for that.

When it runs into an error, the job needs to be aborted in an orderly
manner, and an error object needs to be built.  Any partially built
normal response needs to be discarded.

Both normal and error response object are built pretty much the same
way.  Maybe the same mechanism to pass them around could work for both.

>  I've implemented QError, which (IMHO) is a good enough solution
> for the problem. Will submit it as soon as I get more feedback
> on this last series.

Happy to review that when it's ready.

>> Also any
>> output that doesn't fit into the "run command to completion, report its
>> result" mold (not sure we need that).  We'll see how it goes.
>
>  Do you have an existing example?

It occured to me, i.e. it's purely theoretical until proven to exist.
Thus, "we'll see how it goes".

>> PS: Fun to see Greenspun's Tenth Rule in action once more.
>
>  Let's rewrite qemu in lisp then. :-)

Hey, it would settle the indentation arguments as well!