Don't check on category

John (J5) Palmieri johnp at redhat.com
Tue Nov 8 12:21:47 PST 2005


On Tue, 2005-11-08 at 15:01 -0500, Joe Shaw wrote:
> Hi,
> 
> On Tue, 2005-11-08 at 14:48 -0500, John (J5) Palmieri wrote:
> > A patch was added awhile ago which was a quick fix but not the correct
> > one:
> > 
> > 2005-08-31  Danny Kukawka <danny.kukawka at web.de>
> > 
> >         * fdi/information/10freedesktop/10-usb-music-players.fdi:
> >         Removed merge of not useful key info.category=portable_audio_player.
> >         This merge breakes the storage policy and prevent mount of USB storage
> >         players. See bug: https://bugzilla.novell.com/show_bug.cgi?id=113966
> > 
> > The real fix was to change the storage policy to match on capabilities
> > and not category.  Attached is a patch which does this.  As for the
> > merge of info.category I propose that we nuke this for every device and
> > only rely on capabilities.  It gets confusing and I can see apps in the
> > future running into a bug like this.
> 
> Yeah, your patch is more correct.
> 
> I'm not so sure about removing the merging of info.category, though.  I
> actually think that Danny's patch should be reverted.  The idea being
> that the classic definition of category vs. capability was what the
> device is vs. what the device does.  An audio player should appear as an
> audio player; apps should deal with them as such and present UIs
> appropriate to that.  The fact that they're also a storage device is a
> technical detail... That's what it does, not what it is.

If people think it is important I really don't care if we keep the key.
I'm only pointing out it will be a cause of bugs simply because it is a
lot easier to check a string than a list and programmers are lazy ;-)
Besides, isn't what a device is a product of its capabilities?  What
would the iPod Video be listed as?  A portable_audio_player;
video_player; a whole other category?  I would suspect UI would be
geared towards the capabilities of a device and not the category.

-- 
John (J5) Palmieri <johnp at redhat.com>



More information about the hal mailing list