Tree: UI
From RFID Wiki
Contents |
[edit] User Interface
[edit] Client and implementation modules
The Guardian user interface consists of an implementation module and some client modules. The implementation runs on the Guardian and listens for commands on its GP input channel. The client modules run on some other device like a PC or a Java-enabled cell phone, and interpret user input to assemble GP commands that are transmitted to the implementation module.
UI modules
- impl
- runs on the Guardian. It reads GP messages from its input channel, performs the command, and replies.
- stdin
- a command-line interface to assemble and transmit GP commands over the channel to the Guardian
- Java
- a GUI that runs on Java ME. Currently, S60 Nokia phones are targeted
[edit] User Interface Implementation Modules
[edit] UI Implementation: ACL
The ACL user interface allows a user to load an ACL, activate it, change arbitrary parts of it, and save it. An ACL has a fixed structure in the Guardian's (flash) disk. Each ACL consists of a directory under /acl. It contains, besides some subdirectories, four files that completely describe an ACL:
- example.tags contains definitions of tags and tag sets
- example.context contains definitions of contexts
- example.readers contains definitions of readers and their roles
- example.acl contains definitions of the rules
The names for these files are mandatory, except for the rules file. The rules file name can be overridden, so different ACL rule sets can share the same tags/tag sets, readers/rules, and contexts.
In the implementation, a loaded ACL consists of three copies of that ACL: one is a copy that users can modify at will but which is not automatically activated or saved (the 'user ACL'); one is the original copy; the third is a postprocessed copy that is actually used to generate an ALLOW or DENY verdict for incoming RFID queries.
This setup allows flexible manipulation of the ACL. Changes that the user performs may be meaningless or incorrect without other, accompanying changes, so a two-phase change/commit mechanism is necessary. Besides, the setup allows to recover or to roll back to previous versions.
If the user has made a number of changes that together bring the ACL into a consistent state (again), she can commit the ACL changes. The Guardian software processes the changed ACL to check whether it is correct. If so, a diff is generated in a subdirectory unsaved of the ACL directory, the ACL is postprocessed and the active copy is replaced. The original, unmodified copy of the ACL stays in place.
If the user saves the current ACL, a diff is generated between the user copy (which may have been modified and committed multiple times) and the original. The diff is stored in a subdirectory changelog of the ACL directory, with a version number. The original copy of the ACL is replaced by a clone of the user copy. The files that constitute the ACL are then overwritten.
If a user makes changes but does not commit them, a watchdog timer saves the changes in a third subdirectory uncommitted of the ACL directory.
To link the active ACL to the RFID communication stack, a filter is registered with the RFID port's filter chain.
[edit] UI Implementation: Spoofing
[edit] UI Implementation: Embedded Reader
[edit] UI Implementation: Logging
[edit] UI Implementation: File System
[edit] UI Implementation: System
[edit] UI Implementation: Alerts
[edit] User Interface Module Dependencies
Depends on:
- GP (Guardian Protocol)
- rfid-filter
- implementation: ACL, spoofing, logging
- Bluetooth channel
- (Guardian)
- Serial line
- (Guardian; host)
- Socket
- (emulator)
