Re: [libdc1394-devel] Releasing Version 2.0

[Jon S. <jon...@ho...>]

Yes, this looks like a good idea.  

On Wed, 2007-04-11 at 16:33 +0900, Damien Douxchamps wrote:
> On Wed, 2007-04-11 at 02:59 -0400, David Moore wrote:
> > Instead, I suggest something like these:
> > 
> > dc1394_t * dc1394_new_context (void)
> > void dc1394_free_context (dc1394_t * context);
> > 
> > int dc1394_get_camera_count (dc1394_t * context);
> > dc1394error_t dc1394_list_cameras (dc1394_t * context,
> >     uint64_t * camera_ids, int * num_cameras);
> 
> Are the two functions necessary? Why not simply use the second one?
> Maybe it's just convenient ;)
> 
> > dc1394camera_t * dc1394_new_camera (dc1394_t * context,
> >     uint64_t camera_id);
> > void dc1394_free_camera (dc1394camera_t * camera);
> 
> OK, so most of the code from dc1384_get_cameras() would land in this new
> function, right?
> 
> > int dc1394_get_event_fd (dc1394_t * context);
> > dc1394error_t dc1394_handle_event (dc1394_t * context);
> > 
> > dc1394error_t dc1394_subscribe_bus_resets (dc1394_t * context,
> >     dc1394bus_reset_func callback, void * user);
> > dc1394error_t dc1394_unsubscribe_bus_resets (dc1394_t * context);
> > 
> > typedef void (*dc1394bus_reset_func) (dc1394_t * context,
> >     uint64_t * new_camera_ids, int num_new_cameras,
> >     uint64_t * removed_camera_ids, int num_removed_cameras,
> >     void * user);
> > 
> > The key change here is a new context structure dc1394_t, so there's no
> > longer a need for any global variables.  Instead of getting a list of
> > pointers to all cameras, you would get an array of camera unique IDs
> > using the list_cameras functions.  You could then instantiate as many
> > of
> > those cameras as you want with the new_camera function.
> 
> More flexible, so I vote for it ;)
> 
> > For those users who want to monitor plug/unplug events, they would get a
> > handle to a file descriptor with get_event_fd() and put that fd in their
> > application's main loop.  Whenever the fd becomes readable, the
> > application would have to call handle_event().  They would assign a
> > callback using subscribe_bus_resets(), and the callback would get called
> > whenever there is a bus reset.  The function comes with a list of camera
> > IDs that are new (plugged) and camera IDs that are gone (unplugged) in
> > that particular bus reset.  It would be up to the user to then free any
> > of the now-missing cameras, or to instantiate any of the new cameras
> > with new_camera() if they desired.
> 
> Nice... nice... ;)
> 
> But I'm a bit confused between the fd functions and the event functions.
> Why do you need handle_event() *and* subscribe_bus_resets()? Isn't the
> bus reset callback enough?
> 
> > Since this is such a major API change (but much better IMHO), we have to
> > get it in for 2.0, or else it will have to wait for 3.0.
> > 
> > Thoughts?
> 
> It looks very nice and worth waiting for ;)
> 
> Damien

________________________________________________________________________

http://lug.htc.honeywell.com/people/jschewe [Honeywell Intranet Only]
Help Jen and I fight cancer by donating to the Leukemia & Lymphomia
Society
Here's our website: http://www.active.com/donate/tntmn/tntmnJSchewe
*My views may not represent those of my empoyers