Andreas Jellinghaus wrote:
> > information: Identify selected devices.
> > info.category = 'smart_card_reader'
> > info.capabilities = { 'openct' }
>
> openct or some other software should not matter IMO, why make it a capability?
HAL documentation recommends to discriminate between three types of FDI
files:
- preprobe: Actions before hal starts to identify the device
- information: Collecting information about the device
- policy: Perform actions
Current openct FDI file mixes information (that it is a Smart Card
reader) and policy (call hal addon).
One of possible ways to implement it better is an additional keyword.
Another way would be using of USB IDs known as Smart Card readers in
information and repeating USB IDs of readers known to work in policy.
> > Good idea! But iso7816 could make it more cryptic to ordinary users.
>
> right. stick with "smart_card_reader" category and hope we don't need to
> explain that a "smart_card_reader" is not a "smart media card reader"
> too often? :)
>
> > I can imagine:
> > info.category = 'smart_card_reader'
> > info.capabilities = { 'openct', 'iso7816', 'smart_card_reader', 'usb_ccid'
>
> ccid shouldn't matter. do you need to put the category as capability too?
It is a potentially interesting information, easily detectable from USB
ID.
> we should have "display" and "pinpad" if capabilities are defined per
> category.
> if not, the capability name needs to be longer, so "display" is not mistaken
> with displays (e.g. monitors, lcd etc.).
It is generic, as anybody can query for devices with particular feature
without specifying category. smart_card_reader.display would be OK.
A dumb question. Is following true or only reverse implication is valid?
no keywords => smart_card_reader.class1
smart_card_reader.pinpad => smart_card_reader.class2
smart_card_reader.display + smart_card_reader.pinpad => smart_card_reader.class3
The implication may be specified in FDI syntax:
<match key="info.capabilities" sibling_contains="smart_card_reader.class2">
<append key="info.capabilities"
type="strlist">smart_card_reader.pinpad</append>
</match>
> > I expect one another change in near future: Fedora people will say "Use
> > DeviceKit instead of hal."
>
> maybe we can get their devicekit config file and document how to configure
> device kit, so other distributions don't need to re-invent the wheel.
DeviceKit is not yet complete. Redhat plans to introduce it for Fedora
11 and port applications later.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
