[Pm-utils] Re: Better integration with power management scripts

[Holger Macht]

On Thu 27. Apr - 16:42:07, Matthew Garrett wrote:
> On Thu, Apr 27, 2006 at 04:31:23PM +0200, Holger Macht wrote:
> 
> > And exactly that it the crucial point: "we care about". Who is this "we"?
> > You? Me? Someone else? And exactly because you don't know who "we" is and
> > which application he is using, IMO it is most desireable to support as
> > many applications as possible. Because also users which aren't programmers
> > and aren't able to fix programs use applications ;-)
> 
> We've got two options here:
> 
> 1) We (the distributions) are shipping the software. We can fix it, so 
> this is unneeded.

No distribution can fix all affected applications they are shipping, not
even within a decade. And it's not only a question of fixing existing
applications, but also one of fixing most applications which will be
developed in the future.

>
> 2) Third party vendors are providing the software. They can either (a) 
> provide a drop-in file that fudges with power management, or (b) fix 
> their code to properly conform to the new interfaces.
> 
> (1) doesn't require what you're proposing. (2) only does if they choose 
> course of action (a). Course of action (b) is not significantly more 
> work, but is significantly more correct. Why should we support option
> (a) at all?

Vendors do not _choose_ (a), they simply do it and they already do.

And fixing all affected application and also fixing vendor addons is
simply not realistic. At least I don't know from where distributions
and/or other community developers should take the time and manpower for
that.

Really, I understand and agree with your approach, but it is not doable in
a couple of years. We should work to make this happen in the long run, but
we also have to think about a proper solution for the nearer future.

> 
> > > Do you have any use cases where policy decisions need to be made during 
> > > the suspend process? I honestly can't think of any - all the information 
> > > is available beforehand.
> > 
> > You need this feedback definitely at least at one point: You need to know
> > if the suspend succeeded or not.
> 
> Naively, that's trivial - you're still executing and time has passed in 
> a continuous manner. But hal already has support for this - the dbus 
> method simply returns an error if the script doesn't exit correctly.

Ok, I didn't know that hal already returns the return value of the
script. Good to know...

However, still without a reason why suspend failed which would be needed
for an application to react properly.

But we can play this game over and over again which is not quite
helpful. I still think that interaction from these scripts might be
helpful in future, but we'll see.

> 
> > As soons as vendors put their scripts into this architecture, you don't in
> > which case it might be helpful. But if you don't want to support special
> > setups, but just the plain basic methods that come along with Hal or the
> > distributions you think to know of, that's ok. But then I'm sure it's not
> > the solution that fits most peoples needs.
> 
> No, now you're arguing "We need this feedback because we're providing 
> the ability for people to do broken things". A better solution is "Don't 
> provide the ability for people to do broken things". Figure out what 
> vendors need, and then design for that - don't leave the design so open 
> that people can ship completely crack-addled addons, because they'll do 
> so and the world will be a worse place.

Huh? I'm only arguing this way if you call "special setups" as "broken
things".


Regards,
	holger