========================================================================
The gphoto2 device database (gp2ddb)
========================================================================
Important: This is a prototype the developers can play with. The final
version will probably look much different, so don't invest
too much in it (yet).
References:
[1] http://article.gmane.org/gmane.comp.multimedia.gphoto.devel/2262
Hubert's posting from 2006-01-01 proposing storage in XML.
Note: We try to talk of "devices" and "drivers" instead of "cameras"
and "camlibs" since we also support digital audio players.
=============================================
The idea
========
* Maintain a device database (DDB) of cameras (and audio players),
their abilities etc. independently from the libgphoto2 drivers.
* Updates to the database are much easier to publish than updates to
the drivers which need to be compiled.
* libgphoto2 uses the DDB to find out which driver to load for a
given device.
* drivers use the DDB to read special driver specific information on
that device.
* Other software (HAL, udev, hotplug, etc.) is served by converters
from DDB.
=============================================
The implementation
==================
* A flex/bison based parser for text based config.
* The specific details of the text format is not completely ironed
out yet.
* It is possible to use some HAL device database instead, but do we
really want to require HAL/XML/...? Depends whether we target
embedded or desktop environments.
* print-camera-list prints the current config in the new format
(minus driver internal settings ?)
* driver specific settings can be accommodated using the
driver_options { ... }; section.
* The binary code (stripped) for the test case is about 22KByte. I
suppose we could implement this database in about 35 to 40 KByte.
However, we can probably get rid of some code in the drivers to
compensate.
For comparison:
* The current libgphoto2.so is about 120 KByte stripped.
* libxml2.so is 1.2MB (stripped).
=============================================
The testcase
============
* The testcase check-ddb.sh checks that the CameraAbilitiesList read
from the text database is the same one read from the drivers via
gp_abilities_list_load() - for all 700something cameras.
=============================================
How to test it
==============
* Add --enable-gp2ddb to your ./configure parameters.
* Run "make check".
* Have a look into tests/ddb/.
=============================================
TODO
====
What would need to be done to go into production with this:
* Find a way to integrate the gphoto2 DDB with the HAL device
database, possibly using a sub/superset of the HAL device
database. However, HAL does its stuff in XML, and we probably don't
want libgphoto2 to depend on an XML parser.
* Add driver specific parameters to DDB.
* Rewrite gp_abilities_list_load() to read the data currently stored
in the CameryAbilities records and all driver specific information
from the DDB.
This should probably use a caching approach, i.e. it should check
the mtime of (the files in) /etc/libgphoto2.d/ and compare that to
the mtime of a binary cache file in ~/.gphoto/ddb-cache.
The compiler which creates this cache file needs to be embedded in
libgphoto2 itself (so that libgphoto2 can "just work") but should
also be available as a separate tool for embedded use cases. These
embedded systems could then compile the ddb-cache at build time,
just read in the cache, and not ship the parser/compiler at all.
Another possibility would be to statically compile the binary
version of the database into libgphoto2 for small-footprint
applications.
* Rewrite all drivers to read their device specific parameters from
the new CameraAbilities record.
* Maintain binary compatibility for applications.
* Administration utilities convert the DDB to something HAL, udev, and
other similar hotplug-device-management systems use to figure out
the device type, what program to launch to handle such devices, and
how to set up permissions. This is partly done in print-camera-list.
* Administration utilities to maintain the DDB in the face of
- updates from the gphoto project
- updates by the user
- update by third parties
One solution to the problem could be a directory structure like
/etc/libgphoto2.d/camlib-agfa.ddb # the devices from the agfa camlib
/etc/libgphoto2.d/camlib-canon.ddb # the devices from the canon camlib
/etc/libgphoto2.d/camlib-ptp2.ddb # the devices from the ptp2 camlib
/etc/libgphoto2.d/foo.ddb # devices the user got from somewhere
/etc/libgphoto2.d/bar.ddb # devices the user got from somewhere
* Check whether there wouldn't be an XML parsing library with a much
smaller footprint than the 1.2MB of libxml2.
* The DDB device names should be Unicode strings.
* There must be structured information on device names, e.g. the
vendor must be readable without parsing strings.
* Store other device information in the DDB which may be of interest
for a libgphoto2 frontend, e.g.
- thumbnail images of the devices themselves.
- camera features like capture modes, can delete single files, can
delete all files, can mark downloaded files, can upload files
========================================================================
End of file README.ddb.
========================================================================
69465b70e3