ServiceOwnerChanged wakes up everybody?

[John (J5) Palmieri]

On Thu, 2005-06-09 at 22:27 +0200, Anders Carlsson wrote:
> Havoc Pennington wrote:
> 
> >On Thu, 2005-06-09 at 15:56 +0200, Anders Carlsson wrote:
> >  
> >
> >>Yeah, I did consider that at first but it would add a lot of extra
> >>complexity to the bus (as well as probably slow it down somewhat), and
> >>I'm not sure it would gain that much.
> >>    
> >>
> >
> >Can you spell out what the extra complexity/slowdown would be? I'm
> >probably being dense but I would imagine the implementation looking
> >about the same as the one for the detail.
> >
> >Havoc
> >  
> >
> Wouldn't you have to do a linear search inside each message? If I
> specify arg7='3.14159', wouldn't that mean that all messages would have
> to be searched to see if they had 7 arguments, then checking the message
> type (which you'd also have to specify in the match somehow) and finally
> comparing the message to see if it matches, taking into account the byte
> order.

You would have to iterate over seven elements, demarshal it and then do
the compare.  It looks like the header fields also have to demarshal the
data so...  Also, if one had a match for arg7 and there are only 6 args
I would qualify that as a failed match.  As for the argument type you
would have to check the signature of the iterator and convert the match
rule appropriately.

> Also, I imagine that the matching rule syntax could potentially get
> pretty hairy (with the recursive type system), unless you only want to
> match on toplevel arguments.

I would assume matching could only be done on basic types.

> I think that adding a detail field is simple enough...

The args matching would be more flexible and better defined.  What does
details mean anyway?  It could be anything.  The arguments have more
context associated with them.

-- 
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com