[patch] wireless patch, take 2

[Owen Fraser-Green]

Hi,

> Yeah, it feels kind of gross to me because now we're adding all this
> additional API that people have to learn, when we already have a nice
> property system with just get and set, and we can define all the
> properties pretty cleanly in the spec.  The dbus security features are
> tempting, but is it worth it?
> 
> Joe

No, I don't really think it is worth it. Today, the D-BUS interface
follows a perfect Fasade pattern where the client need only know about
two interfaces. A big black box with two friendly little white boxes
sticking out the top. What we're talking about here is wrenching some of
the innards out of the black bit, just little bits here and there, and
poking them out through little holes. And that's when one of our white
boxes already had various SetProperty methods.

I feel that if the problem cannot be solved without minor changes to the
existing interfaces it's a problem not worth solving. But are the
problems with property.d really insurmountable?

1. SetProperty fails

Can't the SetProperty methods return a bool indicating success? The
client sends and blocks and, if failure, gets an error string instead.

2. GetProperty called during SetProperty

What if all calls to GetProperty are blocked until the result from 1.
has been returned. If we liked then the PropertyChanged signal can still
be emitted as the actual change happens, the clients can then call
GetProperty but they'll be blocked until the result is absolute (in the
meantime it could have changed back to what is was before but that
presumably won't be a problem).

I'm sure there are more nasty corners but I think thrashing them out
here is a better path than messing up the fasade but that's just my kr
2,-.

Cheers,
Owen



_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal