portable_audio_player.type,access_method

[Jeff Mitchell]

Danny Kukawka wrote:
> On Mittwoch, 2. Mai 2007, Jeff Mitchell wrote:
>   
>> Danny Kukawka wrote:
>>     
>> Do you mean 3 keys, or 3 values?  I count two keys listed above, but
>> three values you list (psp, ipod, generic).  If you meant values, I
>> don't see a reason why those three should be allowed but mtp, ptp (the
>> proper value for njb...the protocol is PTP), and the rest shouldn't.
>>     
>
> I meant values. And IMO mtp/ptp etc shouldn't be allowed because they say 
> nothing about the type of the player, they say something about a possible 
> protocol/access method.
>
>   
>> But type (which, remember, isn't defined in the HAL spec) is tied to the
>> access method.  Otherwise they're all just portable music players,
>> period.  Unless you want to define a bunch of values for type like iPod,
>> Sansa, iFP, Zen, Gigabeat, DJ, on and on and on, for every line that
>> every manufacturer has.  After all, iPods aren't special -- they're just
>> Apple's line of music players, just like Zens are Creative's line, and
>> Gigabeats are Toshiba's line.  So there can't be a double standard in
>> terms of what's allowed in type -- either all need to be supported, or
>> none.
>>     
>
> I'm against add all possible product names/lines to the *.type key. This are 
> IMO information which have nothing to do with type and are useless. You can 
> get this information also from the product name.
>   
Then why should there be a distinction for iPods?  iPods are generic 
storage.  They happen to also have a database.  So if you want to allow 
a portable_audio_player.type of ipod, either you're describing the 
product line of the player (iPod, containing models iPod Nano, iPod 
Shuffle, etc..), or you're describing a method that would be used to 
transfer songs to or from it (generic storage + database).

If you're describing the former, then you have to either allow all 
product lines from all manufacturers, or none.  If you're describing the 
latter, you have to allow other transfer methods, such as MTP, PTP, etc. 
as well.  HAL shouldn't be giving iPods special treatment.

FWIW, this is why I suggest removing the portable_audio_player.type key 
entirely, which again, is *NOT* a part of the HAL portable_audio_player 
specification, but is simply used a lot in 10-usb-music-players.fdi.  
Instead I think we should do what you proposed -- 
portable_audio_players.access_method.drivers (libgpod and ipod-sharp, 
libmtp, libifp), and portable_audio_players.access_method.protocols 
(generic and ipod, mtp, iriver).  Then have libxyz.name, libxyz.protocol 
keys.  No chance of key-grabs by protocols that want to be default, no 
special treatment for some players and not others.

> Btw. We need maybe some new FDI derective to allow add a value to the list 
> only if it is not already in, something like 'insert'. This would avoid to 
> check again and again with contains_not if the value is already in the list.
>   
Agreed, although for now I'll just be using contains_not checks -- that 
can always be updated.

--Jeff