« Return to Thread: libusb future

Re: libusb future

by Tim Roberts :: Rate this Message:

Reply to Author | View in Thread

Daniel Drake wrote:
> Indeed, feedback is appreciated. I am not yet happy with the naming
> aspects of the API which I have already meddled with a few times since
> starting the project. Suggestions appreciated.
>
> I can probably guess, but which parts did you find unintuitive?
>  

Well, certainly the "poll" routines do not explain themselves.  I also
don't like "intr" and "devh".  And, since I'm getting picky,
fpusb_dev_get_descriptor implies that it will gets any kind of
descriptor (rather than just the device descriptor), and
fpusb_dev_get_config doesn't mention the word "descriptor".  You don't
have an API to fetch string descriptors yet, do you?

I like APIs that read like a sentence fragment, with a verb and a noun.

> Do you think I should refer to control transfers as "messages" but bulk
> ones as something else? (i guess yes). libusb_submit_bulk_transfer()?
> libusb_submit_bulk_urb()?
>  

Personally, I would refer to all of them as "transfers".  The message vs
stream distinction in the spec is not really very useful.  From a
software point of view, control, bulk, and interrupt transfers are
identical, except that some control transfers have a pre-defined format.

I'm torn about how to handle the naming of sync vs async routines, even
in my own code.  Although "libusb_submit_bulk_urb" accurately reflects
what the routine does, in fact the libusb user doesn't know about or
think in terms of URBs.  That is an implementation detail.

I could be talked into this:
    libusb_submit_bulk_transfer
    libusb_submit_bulk_transfer_async
or this:
    libusb_submit_bulk_transfer_and_wait
    libusb_submit_bulk_transfer

--
Tim Roberts, timr@...
Providenza & Boekelheide, Inc.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

 « Return to Thread: libusb future