
CVSID:$Id: TODO,v 1.38 2004/09/17 17:22:27 joe Exp $
 
This document is the TODO list for the HAL project. Feel free to
add/remove entries if you get an idea or implement one of these. If
you want to work on one of these you might want to send a patch that
updates this file to reflect it.

============================================================================
* Ensure that all children are removed before removing a device
============================================================================

Especially this causes problems for the tools/fstab-sync code.

============================================================================
* Rescan() method on HalDevice
============================================================================

The idea is that HAL exports a generic operation to 'rescan' a device
where the semantics of this operation is highly dependent on the actual
HalDevice. 

For example, this is needed when we don't poll for media, so e.g. the
semantics of the operation on devices of capability block where
block.is_volume is FALSE is to poll for media (and note on Linux this
is highly dependent on whether it's a legacy floppy drive, USB floppy
drive, an optical drive or a cardreader; partitions or not, etc.

If we support legacy serial ports it might mean 'search for a modem'.

============================================================================
* Privilege management
============================================================================

We need to ensure that non-root can only read the properties. This is
very important to do before anyone starts shipping HAL in a stable
distro.

This poses an interesting question on how gnome-volume-manager
works. g-v-m adds the capability content.photos to a volume if a DCIM/
tree is found in the root. Perhaps HAL should take care of this? Another
option is to use the GetUnixProcessID(), see below.

Anyway, for this we'll need D-BUS 0.22 since the GetUnixProcessID() and
GetUnixUser() only hit CVS some weeks ago. Ideally D-BUS should support
policy for this, see

 http://freedesktop.org/pipermail/dbus/2004-July/001309.html

but this is not going to happen as it requires root. 

Sigh. We can still do this, we've only have to maintain the policy
ourselves in /etc/hal/hald.conf, e.g. say
/usr/bin/gnome-volume-manager is allowed to do stuff. 

============================================================================
* Input devices
============================================================================

We should somehow expose the protocol used; e.g. for input.device we
should have input.protocol=Linux|PS2 etc.

============================================================================
* More property types
============================================================================

The gstreamer guys expressed desire for some more property types; here's
some ideas

 - lists; should by of ANY type; info.capabilities should probably be
   a list of strings

 - ranges, e.g. [3.4;43.2[, [2.0;3.0]

 - .fdi files should be able to match on new types

============================================================================
* .fdi files
============================================================================

This really needs to be thought through. Ideally we should be able to
do stuff like this

<deviceinfo version="0.2">
  <device>
    <match key="info.bus" string="usb">
      <match key="usb.vendor_id" int="0x066f">
        <match key="usb.product_id" int="0x8000">

          <merge key="info.category" type="string">portable_audio_player</merge>
          <merge key="info.capabilities" type="string">portable_audio_player</merge>
          <merge key="portable_audio_player.output" type="string">mp3 wma</merge>
          <merge key="portable_audio_player.input" type="string">wav</merge>
          <merge key="portable_audio_player.localdb" type="bool">false</merge>

          <match udi="root" key="kernel.name" string="Linux">
            <merge key="blah" string="pre-foo">
            <match udi="root" key="kernel.version" version_ge="2.6.42">
              <merge key="blah" string="new-foo">
            </match>
          </match>

          <match udi="root" key="kernel.name" string="FreeBSD">
            <merge key="blah" string="bsd-foo">
          </match>

        </match>
      </match>
    </match>
  </device>
</deviceinfo>

where using udi="<X>" means reference the property on the device with
UDI <X>. 

The 'version_ge' attribute means to read the string property (good
idea or should version tupples be a primitive type?) kernel.version
and see if it's greater than 2.6.42. Clearly, this must work for
vendor kernels etc., e.g. 2.6.47-1.492smp would also match.

============================================================================
* Run callouts for shutdown, startup, normal operation
============================================================================

 - For startup, hald should run the callouts (it does already) but the
   environment should export

    HALD_HOTPLUG  = false
    HALD_STARTUP  = true
    HALD_SHUTDOWN = false

   and no D-BUS signals should be emitted. This applies only for devices
   that are not newly detected.
   (without persistency all devices are newly detected)

 - When detecting device add/remove while running, hald should export this
   in the environment

    HALD_HOTPLUG  = true
    HALD_STARTUP  = false
    HALD_SHUTDOWN = false

   and D-BUS signals should be emitted.

 - When hald recieves a SIGTERM the callouts should be run with 'remove'
   and the environment should export

    HALD_HOTPLUG  = false
    HALD_STARTUP  = false
    HALD_SHUTDOWN = true

   no D-BUS signals should be emitted.

============================================================================
* Additional properties on the "Computer" Root HalDevice
============================================================================

The Computer HalDevice needs to contain additional info about the system.
Right now it just exports some basic kernel info (name, version).  It
should also include things like the X.org version, power management info
(see below), etc.

============================================================================
* UTF8 support
============================================================================

All string handling functions need to use UTF8.


============================================================================
============================================================================
 NEW MAJOR RELEASE, UPDATE SPEC
============================================================================
============================================================================

============================================================================
* Removal of class devices
============================================================================

Add support for removal of class devices - we should probably remove
the properties merged and send out a d-bus signal; see comments in
hald/linux/osspec.c:remove_class_device(). This can now easily be
tested with modprobe and rmmod on the sg kernel module


============================================================================
* .fdi file enhancements
============================================================================

There needs to be a way to match on capabilities in the FDI files.
It'd also be nice if there were author/maintainer info in there.

One way to implement this is using an existing PKI framework.  There
should be an easy way to sign an .fdi file e.g. a hal-sign-fdi
tool. There should also be a directory where vendors can easily drop
the public key.

Also, we should probably consider emitting a dbus-signal or setting a
property so desktop environments can figure display an appropriate
dialog with the .fdi file is unsigned. Probably needs discussion on
the mailing list.

============================================================================
* Persistent device store
============================================================================

Kay Sievers has implemented parts of it, see

     http://freedesktop.org/pipermail/hal/2004-June/000388.html

for details and discussion. This mail also covers things like clean
shutdown


============================================================================
* Power management
============================================================================

There is already some discussion here 

 http://freedesktop.org/pipermail/hal/2004-July/000544.html

about abstracting both ACPI and pmud. Ideally we would also have Suspend()
and Resume() methods on HalDevices.

============================================================================
* Support for more bus-devices and class-devices
============================================================================

Some low hanging fruit might be video4linux stuff

============================================================================
* Testing
============================================================================

Testing framework; probably only feasible for non-os specific code,
e.g. the whole callout, device and device store framework

============================================================================
* Caching in libhal
============================================================================

Caching in libhal; the API is ready for it. Remember you cannot use
glib or other dependencies; we can only depend on libc and dbus!


============================================================================
* Property access control and per-user properties
============================================================================

Non-root users should only have read-access to the devices except in
properties where the key starts with 'user.'. Also properties starting
with 'user.' should be per-user (and per-box, e.g. don't save them in
a dotfile or dotdirectory in the users homedir; see TODO item for
persistent device store)

============================================================================
* Callouts
============================================================================

Callouts are currently called in order, so if a callout hangs then no
others will be called.  There should be a timeout which kills the
callout after a certain period of time.  (5 seconds?  10?  15?)

============================================================================
* Dependencies, Robustness
============================================================================

It would be good to rewrite hald in the paranoid D-BUS handle-OOM etc. style
and get rid of glib, gobject dependencies.
