I would also love to see a community-maintained dc1394 driver in ros-pkg. I'll echo that for inclusion in camera_drivers it would need to follow the same interface as the existing drivers, which we've put in some effort to standardize so that they work interchangeably with the image_pipeline. The docs are useful resources for these stacks:
* http://www.ros.org/wiki/camera_drivers
* http://www.ros.org/wiki/image_pipeline
One design decision we made is that camera drivers need not do any processing of image data, not even debayering or undistortion. This keeps them low-dependency (no OpenCV needed). From a systems perspective it is nice to keep those concerns separate. The camera driver is only responsible for getting data off the camera and into ROS.
The basic processing (debayering and undistortion) is handled by image_proc (or stereo_image_proc). It uses OpenCV functions. The OpenCV debayering functions are admittedly pretty basic; eventually we may make that plugin-based, so that people who are particular about their debayering methods can substitute in something more advanced like the libdc1394 implementations.
To work well with the image_pipeline packages the driver need only publish synchronized image_raw and camera_info topics. set_camera_info is used only by camera_calibration as a convenience, so that you don't have to store the calibration to the camera as a separate step.
The request_image service is only for drivers implementing the polled camera interface. This is useful for high-def cameras like the 5Mp Prosilica we use, as sending those images at frame rate chews up a lot of bandwidth and you're unlikely to do any non-trivial processing on them in real time anyway. Polled camera support might be nice to have in a generic dc1394 driver but is hardly a blocker.
image_transport is designed to mimic the core roscpp classes as closely as possible, so I hope it is not difficult to integrate. In particular see the CameraPublisher convenience class.
Cheers,
Patrick