TODO - pub/scm/libs/libgpiod/libgpiod - Git at Google

 TODO list for libgpiod

 ==========

 This document contains the list of things I'd like to have in libgpiod before
 declaring it "mostly feature-complete". If anyone wants to help, this can
 serve as the starting point.

 ==========

 * implement dbus API for controlling GPIOs

 A common complaint from users about gpioset is that the state of a line is not
 retained once the program exits. While this is precisely the way linux
 character devices work, it's understandable that most users will want some
 centralized way of controlling GPIOs - similar to how sysfs worked.

 One of the possible solutions is a DBus API. We need a daemon exposing chips
 and lines as dbus objects and allowing to control and inspect lines using
 dbus methods and monitor them using signals.

 As of writing of this document some of the work has already been done and the
 skeleton of the dbus daemon written in C using GLib has already been developed
 and is partially functional.

 ----------

 * implement a simple daemon for controlling GPIOs in C together with a client
   program

 This is by far the lowest priority task. Similarly as with the dbus daemon:
 the goal is to provide a centralized agent controlling GPIOs with a simple
 interface consisting of a command line client communicating with the server
 over unix sockets.

 In this case however the goal is to have as few dependencies as possible. This
 is because for some small systems dbus is overkill. Since we won't be using any
 standardized protocol, it will take much more effort to implement it correctly.

 ----------

 * re-write the python bindings to make them more 'pythonic'

 There are several problems with the current python API. For instance: instead
 of methods, properties should be used wherever possible (chip's name and label,
 line's direction, active-state etc.), we should probably store the line objects
 within the chip instead of creating them everytime get_line() is called and
 several more.

 The idea is to create a new Python module with a different name and convert
 the current gpiod module into a compatiblity layer that would simply translate
 the calls from the new interface to the old one - this way we won't break
 existing programs.
	TODO list for libgpiod

	==========

	This document contains the list of things I'd like to have in libgpiod before
	declaring it "mostly feature-complete". If anyone wants to help, this can
	serve as the starting point.

	==========

	* implement dbus API for controlling GPIOs

	A common complaint from users about gpioset is that the state of a line is not
	retained once the program exits. While this is precisely the way linux
	character devices work, it's understandable that most users will want some
	centralized way of controlling GPIOs - similar to how sysfs worked.

	One of the possible solutions is a DBus API. We need a daemon exposing chips
	and lines as dbus objects and allowing to control and inspect lines using
	dbus methods and monitor them using signals.

	As of writing of this document some of the work has already been done and the
	skeleton of the dbus daemon written in C using GLib has already been developed
	and is partially functional.

	----------

	* implement a simple daemon for controlling GPIOs in C together with a client
	program

	This is by far the lowest priority task. Similarly as with the dbus daemon:
	the goal is to provide a centralized agent controlling GPIOs with a simple
	interface consisting of a command line client communicating with the server
	over unix sockets.

	In this case however the goal is to have as few dependencies as possible. This
	is because for some small systems dbus is overkill. Since we won't be using any
	standardized protocol, it will take much more effort to implement it correctly.

	----------

	* re-write the python bindings to make them more 'pythonic'

	There are several problems with the current python API. For instance: instead
	of methods, properties should be used wherever possible (chip's name and label,
	line's direction, active-state etc.), we should probably store the line objects
	within the chip instead of creating them everytime get_line() is called and
	several more.

	The idea is to create a new Python module with a different name and convert
	the current gpiod module into a compatiblity layer that would simply translate
	the calls from the new interface to the old one - this way we won't break
	existing programs.