Wishlist/Point of Interest Framework

From Openmoko

Revision as of 13:24, 31 August 2008 by DolfjeBot1 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Wishes warning! This article or section documents one or more OpenMoko Wish List items, the features described here may or may not be implemented in the future.

Contents

Point of Interest Framework

This feature may serve as framework for Wishlist:context_based_to-do_list and Wishlist:Location_based_reminders. The idea is to notify the user of certain events based on their location, direction, or any event a daemon is able to trigger.

Tagging may be used to filter or control a called application.

It should be tightly connected to Wishlist:ANARM and Wishlist:Profiles

Use Cases

It combines the use case of Wishlist:context_based_to-do_list and Wishlist:Location_based_reminders

  • Let any application or daemon start another application by simple rules defined in a GUI
  • A daemon checks for location POIs and call the events (aka. starts applications or do dbus calls) that are tied to the tags of that POI
  • A daemon checks for the GSM cell id you are in and activates an certain user profile
  • A daemon checks for near Bluetooth devices and call an event if a device matches
  • ...checks for your WiFi SID and do the VPN connect to your home network
  • Cron starts an alarm and therefore the associated events at a specific time
  • A simple script polls a log file, finds some uncommon connection attempt on your log file an give you a notice


Design Ideas

  • It should be a GUI based application and a daemon
  • It should be a bidirectional daemon, allowing a applications to drag out a list of POI objects tagged for itself and being called by an application with event 'bar' and parameters 'foo' or tags 'foo-bar'
  • This application itself should to two sided
    • one side a few standard input daemons or triggers like GPS, time or 'just a few tags' with a specific dialogue for each type.
    • The other side is the event what would be called like calendar events='tag a' or show notification with specific dialogs for each know event type and a command line incl. parameter expansion. For powerusesr there should be the possibility to do a D-Bus call as well.
  • each input can be connected to each event just by dragging them onto
    • these connection should be 'or' by default and group able by an extra dialogue. So powerusers can specify like (Input A and Input B) or Input C or even full boolean trees. The application may aggregate triggers or several seconds to accomplish that.
  • once configured it may run as permanent daemon and awaits incoming triggers
  • new event types should be easy to implement by an XML configuration file, so the user just installs a package and that drops the appropriate config file for that daemon.
  • new inputs/triggers should by configurable by XML too
  • import / export of selected connection between triggers and events

Design Issues

  • How to hide the complexity of this system for Joe Doe? - Different levels of complexity? perhaps from Noob to Pro? See Wishlist:Profiles for more details
  • How to handle multiple times the same event? Like staying at a certain GPS location should the event triggered more then once?
  • There should be an import for several GPS based POI[1] formats

Existing Technologies

  • GPS devices checking for POIs and show them on map or warns the user [2]
  • inetd does that for network traffic on specific TCP or UPD ports
  • D-Bus[3] or DCOP[4] does a lot of this but doesn't offer a GUI
Personal tools
Wishes warning! This article or section documents one or more OpenMoko Wish List items, the features described here may or may not be implemented in the future.

Point of Interest Framework

This feature may serve as framework for Wishlist:context_based_to-do_list and Wishlist:Location_based_reminders. The idea is to notify the user of certain events based on their location, direction, or any event a daemon is able to trigger.

Tagging may be used to filter or control a called application.

It should be tightly connected to Wishlist:ANARM and Wishlist:Profiles

Use Cases

It combines the use case of Wishlist:context_based_to-do_list and Wishlist:Location_based_reminders

  • Let any application or daemon start another application by simple rules defined in a GUI
  • A daemon checks for location POIs and call the events (aka. starts applications or do dbus calls) that are tied to the tags of that POI
  • A daemon checks for the GSM cell id you are in and activates an certain user profile
  • A daemon checks for near Bluetooth devices and call an event if a device matches
  • ...checks for your WiFi SID and do the VPN connect to your home network
  • Cron starts an alarm and therefore the associated events at a specific time
  • A simple script polls a log file, finds some uncommon connection attempt on your log file an give you a notice


Design Ideas

  • It should be a GUI based application and a daemon
  • It should be a bidirectional daemon, allowing a applications to drag out a list of POI objects tagged for itself and being called by an application with event 'bar' and parameters 'foo' or tags 'foo-bar'
  • This application itself should to two sided
    • one side a few standard input daemons or triggers like GPS, time or 'just a few tags' with a specific dialogue for each type.
    • The other side is the event what would be called like calendar events='tag a' or show notification with specific dialogs for each know event type and a command line incl. parameter expansion. For powerusesr there should be the possibility to do a D-Bus call as well.
  • each input can be connected to each event just by dragging them onto
    • these connection should be 'or' by default and group able by an extra dialogue. So powerusers can specify like (Input A and Input B) or Input C or even full boolean trees. The application may aggregate triggers or several seconds to accomplish that.
  • once configured it may run as permanent daemon and awaits incoming triggers
  • new event types should be easy to implement by an XML configuration file, so the user just installs a package and that drops the appropriate config file for that daemon.
  • new inputs/triggers should by configurable by XML too
  • import / export of selected connection between triggers and events

Design Issues

  • How to hide the complexity of this system for Joe Doe? - Different levels of complexity? perhaps from Noob to Pro? See Wishlist:Profiles for more details
  • How to handle multiple times the same event? Like staying at a certain GPS location should the event triggered more then once?
  • There should be an import for several GPS based POI[1] formats

Existing Technologies

  • GPS devices checking for POIs and show them on map or warns the user [2]
  • inetd does that for network traffic on specific TCP or UPD ports
  • D-Bus[3] or DCOP[4] does a lot of this but doesn't offer a GUI