Hi Thomas, 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. Use cases: 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 picture. Best regards, Bjarne Vestergaard 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[1]. > > 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? > > Regards, > > Thomas > > > > [1] http://www.ietf.org/rfc/rfc2445.txt