portable_audio_player.type,access_method

[David Zeuthen]

On Wed, 2007-05-02 at 00:43 -0400, Jeff Mitchell wrote:
> So the ways around that are either making the
> portable_audio_player.type 
> (which isn't even in the HAL spec, though it's used in 
> 10-usb-music-players.fdi everywhere) a strlist, or removing 
> portable_audio_player.type entirely in favor of something like my 
> access_handlers key, perhaps with (mandatory?) libfoo.protocol=foo and 
> libbar.protocol=bar entries.
> 
> Whatever of these methods people think would be better I'll be 
> "standardizing" in the sense of making libmtp, libnjb, libifp, libgpod 
> and libkarma all look the same, and hopefully other libraries will 
> follow suit.
> 
> 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)?

I'm pretty sure it doesn't have to be per library namespace since these
libraries usually don't care about the actual container (e.g. ogg)
and/or encoding (e.g. vorbis or theora). The libraries simply just
transfer files if I understand correctly.

So I think we should add a new fdi operation, in addition to <merge>,
<append> and <prepend>, called <addset> that treats the strlist like a
set e.g.

 <addset key="foo.bar" type="strlist">baz</addset>

appends the value 'baz' iff it doesn't exist already.

We then add this to both 0.5.9.1 and HEAD and start using it in hal-info
and elsewhere. This means we need to advise people running 0.5.9 to
upgrade to 0.5.9.1 (or include the patch) if they use a more recent
hal-info release. Which is some extra work but otherwise fine and all;
if distros don't want to do this they need to patch future hal-info
releases. It's a little bit harsh but since 0.5.9 was released I think
we can make an exception for this.

So I did this.

http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=6a3d21ee7d309c8107098e175f8d15f8ea191684;hp=b023f793ea9791acdda64fbab5b3536deb793454
(also cherry picked to 0.5.9 branch)

Would this work for you? (the operator is useful for other things too)

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

I'd prefer to deprecate it; we have a section in the spec for that. And
also just add it to the spec for completeness of course.

> 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.

Yeah, I like this.

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

Renaming it would break other apps. Perhaps we can just use this
namespace for these devices too - it's not really important what the
name space is called anyway; it's all defined by the MIME types
anyway... Does that make sense?

    David