portable_audio_player.type,access_method

[Danny Kukawka]

On Mittwoch, 2. Mai 2007, Jeff Mitchell wrote:
[...]
> portable_audio_player.type right now in my files I have set to
> (including your values from above):
[..]
> karma
> iriver

Which meaning have these both values? Which driver/lib/protocol is needed for 
them?

[...]
> Just as a recap, the three things I need to get opinions about (plus one
> bonus):
>
> 1) MIME types -- simply enclose all of them in contains_not checks, or
> make them attributes of a library's namespace (in which case the HAL
> spec needs updating)?

You mean MIME types of playable/recordable files?

> 2) portable_audio_player.type -- turn into a strlist, or deprecate?  It
> doesn't seem to make sense the way it is now.

Not sure about this. See other mails

> 3) portable_audio_player.handlers -- David seemed to like this idea
> before, but to the broader audience, do you like this idea?  I think it
> makes sense, rather than doing some random searching through keys.
> Check this to see what libraries are installed that support it, then you
> know which keys to check for (and only need to look at a particular
> library's keys if you prefer one over the other).  Plus it's info the
> user could find handy, and it doesn't really stand a risk of bad
> interactions between libraries as they'd just be appending.

I proposed portable_audio_player.access_method.drivers but could also live 
with portable_audio_player.access_method.handlers, but I would add 
access_method to clarify the meaning of the property.

> Bonus) Should portable_audio_player be renamed to portable_media_player
> since so many of them these days can handle photos and videos?

I would not rename the namespace. If needed (not sure about), we can add a 
portable_video_player namespace. I would vote against one for photo.

Danny