portable_audio_player.type,access_method

[Jeff Mitchell]

David Zeuthen wrote:
> Hi,
>
> So, as some sort of conclusion, I think we should have
>
>  portable_audio_player.type (optional, string)
>
> that can assume a set of well-defined values in the spec. This allows to
> do stuff like choosing an appropriate icon, name etc. for the device. We
> can merge this from a number of places
>
>  - hal-info
>  - 3rd party fdi files
>
> and while these can overwrite each other that would be a bug we'd have
> to work out offline. It's mostly just a hint _anyway_.
>   
In your previous email you said that you wanted to add it to the spec 
(for completeness) and then deprecate this key (in favor of a different 
strlist).  Which one?  Note that part of the problem is what "type" is, 
exactly.  Is it the access protocol (mtp, ipod)?  The device line 
(Sansa, iPod)?  Hence my push for deprecation, in favor of more clear 
methods (below).

> Also, we introduce
>
>  portable_audio_players.driver_support (strlist, optional)
>
> that 3rd party fdi files can set. We should keep a list of known values
> in the spec too. There's no chance of overwriting here since it's a
> string list. We should put text in the spec that apps like Banshee,
> Rhytmbox, Amarok and friends interpret this as what user space driver
> library to use.
>   
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  :-)

Thanks,
Jeff