How about storing the location info (from GPS) for the location where you
picked up a call, received an SMS, or sent an MMS, etc?
You may well question the usefulness of such a feature in comparison to the
features you listed below, but if properly integrated with, e.g., map
services on the WWW, it would be a rather cool feature.
1) "... someone called me when I was at the grocery store - I was supposed to
call back... Who was it... now let me see..."
2) When selecting the "location info" in a record of the communication
history, it brings up the browser to show the spot by means of Google maps.
Perhaps not the easiest use cases to implement, but anyway; you get the
On Wednesday 28 March 2007 16:14, Thomas Wood wrote:
> Hi Mickey,
> We've been thinking about the Communication History use cases, and here
> is the result of some brain storming.
> We decided it would be a good idea if we can store the information in a
> vJournal, which is a format of the iCalendar specification. See section
> 4.6.3 of the iCalendar specification.
> In addition to the fields that iCalendar gives us (date, time, contact,
> etc.), we will need some extra encoded information:
> Entry types
> - SMS
> - Call
> - Voice Message
> Extra Call information
> - Duration
> - Type: Received, Dialled
> - Missed flag
> - "Read" flag
> Extra SMS information
> - "Read" flag
> The idea is to build this functionality into a new light-weight library
> that will hide the complexities of libecal. The API for this library
> will need to be very simple and easy to use, as it will be used in
> several applications across OpenMoko (contacts, dialer, gsmd). Here are
> some use cases:
> * Add new entry
> * Remove entry
> * Mark entry (e.g. SMS or Missed Call) as "read"
> * Search Use Cases
> - Find all "unread" missed calls
> - Find all "unread" SMS
> - Last 10 entries for Person
> - All dialled numbers
> Can anyone add any use cases to this list, or extra information that
> should be stored in the journal?
>  http://www.ietf.org/rfc/rfc2445.txt