Thomas Wood wrote:
> * Search Use Cases
[...]
> - Last 10 entries for Person
I hope you mean "N" :-) E.g., when I call a person, I may want to be
able to quickly retrieve all relevant communication, no matter how old.
("Do you remember the address of that restaurant we went to last time
we've been in Madrid, some three years ago ?")
There's also the question of how far you want to go with this
middleware component. Since such a contact database may be huge (e.g.,
I'd just want to keep everything that I've ever become aware of. I'm
good at remembering meta-data, but actual content quickly evaporates
from my mind.), and retrieval methods sophisticated, a "short term vs.
long term memory" approach might be appropriate.
For now, we'd only need the "short term memory", but it should be
designed in a way that doesn't lead to overly convoluted solutions
for the "long term memory", once someone tackles that. In particular,
there should be a clean way for moving objects between the two.
The "long term memory" would also take care of offline synchronization
and all that (there comes SyncML ;-), so by introducing this "long
term memory", we could leave implementation details of synchronization
aside for now, as well.
Furthermore, this database, which I assume would be fundamentally
tied to the phone, would have to be partitioned by SIM card and
perhaps even for users or roles per SIM card (e.g., company phone with
company card). "Partitioned" may sound complex. Just some
file://${IMEI}/dir/commhist-${IMSI}-${USER}.db would do nicely.
Obviously, in the greater scheme of things, one would probably also
want to be able to migrate all this across phones, i.e., hide the
IMEI part from the user. This would be particularly appreciated by
users who have the habit of constantly losing or breaking their
phones. They obviously represent a much sought-after market
segment :-)
Hmm, this is getting complex. Another approach would be to save all
these nice ideas for a version 2, and design the current thing with
simplicity and a hard incompatibility between version 1 and version 2
in mind. Users and roles should be handled at a more general level
anyway, and the end-user probably shouldn't have to bother with such
abstract concepts anyway.
Oh, and a way to associate "user-provided" data with a record would
also be very useful. That doesn't have to be a writeable field. Just
a read-only statistically globally unique ID for each entry would
do nicely. (E.g., I may want to keep recordings of all calls I make,
but having that as a standard feature would get us into hot legal
water quickly.)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net/____________________________________________/
