On Fri, 2008-11-07 at 13:34 +0000, Richard Hughes wrote: > On Thu, 2008-11-06 at 12:26 -0500, David Zeuthen wrote: > > On Thu, 2008-11-06 at 16:47 +0000, Richard Hughes wrote: > > > I’ve put an interface file up here: > > > http://people.freedesktop.org/~hughsient/DeviceKit-power/gtk-doc/Latency.html > > > > Some comments > > > > 1. Regarding GetRequests() returning a(ussi), e.g. an array of > > > > - pid, connection, type, value > > > > why is the connection necessary? > > If more than one process has two different requests -- mainly so the > application didn't have to track it's own requests. For instance, you > could have one request from two different GObjects. Think of it like a > cookie.
If a cookie is what we want (and I think we do), we shouldn't implement it this way. Second, everything in a process share the D-Bus connection so this wouldn't be a very good cookie anyway. (In general, we should avoid exposing transport details like the D-Bus connection as people might want to wrap our D-Bus interface behind a RPC thing like func / SOAP / XML-RPC etc. for cluster-like systems.) > > For that you want a bit more than information actually, you need > > something like this > > > > http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device.FilesystemListOpenFiles > > With the PID, can't we get all this other stuff? Today you can get this on Linux, in the future, who knows if you can read /proc/<pid>/ if it's owned by another user. The point is really that if you're providing this for an admin-like user interface (and we are) then it's likely that user interface will need that kind of information. So better expose it. > > that uses more suitable names / icons for representing the applications > > with active outstanding requests. You probably also want to lock this > > method down using PolicyKit and default to granting the authorization to > > active local sessions. > > You think we need to lock down this method? Surely anyone can read /proc > and get essentially the same data. Maybe not. But we need to lock it down in case /proc can't be read in the future. > > 4. What's the difference between SetLatency() and SetMinLatency() > > anyway? When would I use on over the other? > > The latter would be set by an admin to over-ride the latency request for > applications. Why wouldn't the admin just use the same method? I'm not sure why we need two separate methods. I mean, with a CancelLatencyRequest() and proper user interface the admin can just remove requests that way. > > > 5. How do I undo a latency request? Probably the Request* methods needs > > to return a cookie and we need a CancelLatencyRequest() method to cancel > > it that you pass the obtained cookie in. > > I figured the connection would be disconnected or the client could do > Request(-1). If this is done per-connection, I don't think we need to > return a cookie. I think we want a cookie. > > 6. Should we return the cookie in the GetRequests() thus allowing other > > clients to cancel a request? Maybe > > I hadn't thought of that. That's probably the exact sort of thing you > would do on the admin interface. Returning a proper cookie would allow > us to do that. Right, I think that makes sense. > > 7. GetLatency() is probably the right name since it will be computed > > from the set of outstanding requests. What does it return if there are > > no outstanding requests? > > I guess -1, although that needs to be in the docs. Isn't there a default latency we can read from somewhere? If possible, I definitely think we want to return something meaningful instead of e.g. -1 meaning "not set". I mean, with the system running and all, I think there is *some* default latency set even when no application has asked for it... David _______________________________________________ devkit-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/devkit-devel
