DBus method naming of upower/udisks

[randyf at sibernet.com]

On Thu, 10 Dec 2009, David Zeuthen wrote:

> On Thu, 2009-12-10 at 09:09 +0100, Martin Pitt wrote:
>> udisks already uses org.freedesktop.UDisks, and I expect upower will
>> change similarly.
>
> Right - and I think udisks, it being the project name is pretty OS
> neutral so I don't see any problem in using it in public interfaces. I
> also don't think we have any Linux specific bits in the interfaces.

   I don't mean to be disrespectful, but it doesn't surprise me that this 
is considered OS neutral.  However, the fact that "U" sits prominantly in 
the name implies that it is derived from 'udev': a Linux-only facility.

   Even 'LinuxMdStop' below is *not* OS agnostic., and suggested the btrfs 
interfaces below imply that "others should conform to Linux" (why not 
"there are interfaces for ZFS which might look similar to what btrfs will 
need" - though  this would imply a different OS centricity).

   I would go further to state that unless that the primary contributors of 
these names or interfaces is not _actively_ using at least 3 different 
OSes (versions or relicants of one doesn't count), providing either claims 
or code to the common good as OS neutral, is a non-sequitor (and, dare I 
say, this is sounding more like the Windows Borg collective).


   IM(very)HO, the fundamental problem with Devicekit (and friends, 
including UDisks and UPower), is that the name of the provider is defined 
*instead of* the name of the desired service.  If there is *really* an 
intent to be OS neutral, then describe first the service that is desired 
(i.e. power, suspend, halt, etc.), and let an arbitrary provider handle 
this service.


   So, going back to what Jedy may have started to suggest (and focusing on 
a single service: power), the *common* service that *ANY* (pardon the 
shouting) OS will implement is "power".  This would, in it's most basic 
form, include "halt/shutdown", "restart/reboot", and "suspend".  No matter 
what OS or hypervisor, I believe that these are the primary three states 
of "power" that will be implemented by all.  These would be best presented 
in a DBus name as:

    org.freedesktop.power

with the addition of subordinate services:

    org.freedesktop.power.halt
    org.freedesktop.power.restart
    org.freedesktop.power.suspend

   It would be not only trivial for any provider, including UPower, to be 
the sole (which also, IMHO, is key to any OS) provider to these services, 
without a definition as to _how_ these providers should perform this 
service.  Given the above, there could be any arbitrary application (say, 
GPM) that could give the user a common view into how to manage *any* OS 
(including the dreaded Redmond OS).  This is what I believe to be an OS 
neutral view.

   Now, I grant that this is a hard problem to solve, but it should always 
start with "what is the problem we are trying to solve", rather than "what 
is the tool we need to use to solve the problem".

rf

>
> Note that method names such as LinuxMdStop() isn't really related to
> "Linux, the kernel" or "Linux, the OS" - instead it's related to the
> on-disk format of (Linux) MD software raid and associated tools (e.g.
> mdadm(8)) and drivers (e.g. md(4)). Ditto for things like LuksLock()
> referring to LUKS (Linux Unified Key Setup).
>
> Presumably non-Linux OSes (or non-Linux kernels) could implement both
> Linux MD-RAID and LUKS - if not, implementations can just return the
> NotSupported error.
>
> FWIW, we can always add similar interfaces for e.g. FreeBSD geom or ZFS
> or whatever - FWIW, I'm planning to add interfaces for better btrfs
> integration - might look similar to what ZFS will need.
>
> Thanks,
> David
>
>
> _______________________________________________
> devkit-devel mailing list
> devkit-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/devkit-devel
>