portable_audio_player.type,access_method

[Jeff Mitchell]

David Zeuthen wrote:
> On Thu, 2007-05-03 at 00:20 -0400, Jeff Mitchell wrote:
>   
>> Instead of driver_support, I'd rather see two keys, like how Danny 
>> proposed: drivers and protocols.  Many apps don't need to know which 
>> drivers a device use, only which protocol it talks (and then it figures 
>> out what handler it wants to use).  But likewise there are reasons for 
>> listing the drivers as well.
>>
>> 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  :-)
>>     
>
> I think we mean the same thing. I guess what I wanted to achieve was
> simplicity; e.g. app authors for e.g. Banshee does not care about
> protocols at all; they just care what library to use to transfer a file
> to the device right? That's my guess but then again, I don't write apps.
>   
Yes, but we care about what protocol it is to pick the library.  :-)  
Because we may or may not have support for any particular installed 
library (since they have different APIs, use different languages, etc.)  
So for me at least, it's the other way around -- I care about what 
protocol, and use that internally to pick the library.  But other apps 
may be different and care about the libraries not the protocol, which is 
why having both keys can be good.
> So I guess I'm just confused by all the prose mail. Maybe if you and/or
> Danny could post a more formal definition of what properties to
> add/remove/change (preferably as diff to the spec) it would be more
> clear? Thanks!
>   
Sure.

--Jeff