7d982f06b9
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@9105 67ed7778-7388-44ab-90cf-0a291f65f57c
102 lines
3.1 KiB
Plaintext
102 lines
3.1 KiB
Plaintext
========================================================================
|
|
The gphoto2 device database (gp2ddb)
|
|
========================================================================
|
|
|
|
Important: This is a prototype the developers can play with. The final
|
|
version will look much different, so don't invest too much
|
|
in it.
|
|
|
|
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 camlibs.
|
|
|
|
* Updates to the database are much easier to publish than updates to
|
|
the camlibs which need to be compiled.
|
|
|
|
|
|
=============================================
|
|
The implementation
|
|
==================
|
|
|
|
* A flex/bison based parser for text based config.
|
|
|
|
* 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? Depends whether we target embedded or
|
|
desktop environments.
|
|
|
|
* print-camera-list prints the current config in the new format
|
|
(minus camlib internal settings)
|
|
|
|
* camlib 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 camlibs 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/.
|
|
|
|
* Possibly add the output of
|
|
(hostname;cat /proc/cpuinfo)|md5sum|cut -d" " -f1
|
|
to the list in configure.in to avoid the --enable-gp2ddb
|
|
requirement.
|
|
|
|
|
|
=============================================
|
|
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 record and all driver specific information
|
|
from the DDB.
|
|
|
|
* Rewrite all drivers to read their device specific parameters from
|
|
the new CameraAbilities record.
|
|
|
|
* Maintain binary compatibility.
|
|
|
|
|
|
========================================================================
|
|
End of file.
|
|
========================================================================
|