portable_audio_player.type,access_method

[Jeff Mitchell]

James "Doc" Livingston wrote:
> On Thu, 2007-05-03 at 00:35 -0400, David Zeuthen wrote:
>   
>> On Thu, 2007-05-03 at 00:20 -0400, Jeff Mitchell wrote:
>>     
>>> But if there's only a driver_support key, I'd recommend that, at least 
>>> informally, each driver should include a [drivername].protocol key that 
>>> specifies what protocol it speaks.  And probably a [drivername].name 
>>> that has a user-friendly device name -- never underestimate the power of 
>>> the right name to make a user feel at ease  :-)
>>>       
>
> Having a user-friendly name in a property starts to get pretty messy if
> you want it to be translatable.
>   
True, but wouldn't that be up to the library providing it?

I suppose usb_device.vendor and usb_device.product should be used instead?

> I'd say that's backwards, because apps use the protocol to figure out
> which library to use, and they don't necessarily use the same libraries
> to access it.
>
> For example, consider an iPod which uses the "ipod protocol" (the
> special database). Rhythmbox uses libgpod to access it, Banshee uses
> (last I checked) libipoddevice, other media players quite possible use
> different libraries.
>
> Given that apps have to be coded to use the API of the library, it isn't
> a problem to have the app map the "protocol" to the library it wants to
> use.
>   
Right.  I still think the libraries strlist should exist however, 
because it provides an easy way for clients to know under which 
namespaces they might find additional keys.

--Jeff