I agree with most of what Alexey said, but I would love to see some sort
of easy to use scripting / gui environment. I think the FSO stuff is
working on some sort of d-bus event notification system. Presumably
there's a set of python / c libraries that know how to talk to dbus, and
provide a simple wrapper on top of everything. (I haven't looked at FSO
or DBUS yet... ;)
I wonder if this is a job for some simple query language like a subset
of xpath or xquery. It could re-evaluate an expression each time a dbus
event could change the expression's results. It would also simplify
writing things like "pause my music when the phone rings", alarm clocks,
etc:
register_event_handler("/phone/incoming_call = true",
mute_music_callback)
register_event_handler("/clock/time = 600",
play_alarm_callback,
"loud_buzzer.ogg")
and so on...
These event handlers could live in a python script (or, better) inside a
simple GUI app.
I think most people that own one of these things knows how to program.
Improving their productivity a bit should be a big win when the consumer
version of the phone ships...
-Rusty
Alexey Feldgendler wrote:
> On Fri, 18 Jul 2008 01:01:08 +0200, matt joyce <[EMAIL PROTECTED]>
> wrote:
>
>> If it can be reliably established that my physical location is one of
>> my favourite restaurants please switch my phone to vibrate, unless my
>> babysitter calls.
>> If I miss a call or I receive an SMS from from any of my work
>> contacts during work hours, and I don't respond, please remind me.
>> If it's not during work hours, do not take any calls from contacts
>> exclusively in my work contacts.
>> If my home wifi is available and my battery is not too low, don't use
>> GPRS for data.
>> If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and
>> start getting email and rss.
>> At 21:00 on weekdays, switch to standby.
>> If my battery is low and I'm at home, remind me to charge.
>> If I'm at home disable my auto-lock.
>
> The problem with this is that one needs to think like a programmer to
> describe your “ideal phone” as a set of rules like these. Not only does
> one have to think analytically and dissect their concept into orthogonal,
> machine-checkable rules, but from your examples it's also clear that for
> such a wide range of possibilities a whole *language* with *expressions*
> (at least boolean) is necessary.
>
> Moreover, if one *is* a programmer, and has learned the rule expression
> language, there will be bugs in the rulesets, like overlooked priorities
> or excessively permissive conditions, and you'll spend some time debugging
> it, probably missing a few important calls and alarms now and then in the
> process. Next step would be debugging tools for rulesets, allowing to
> simulate times of day, different conditions and incoming events to test
> the rules. Next, backup and revision control for rulesets. This is where
> madness lies: you have to modify and debug a program in a declarative
> logic language when you start dating someone because it breaks all your
> carefully polished ruleset. Sounds like a topic for XKCD. Randall, are you
> by any chance reading this?
>
> I understand that you must be thinking, “This phone is fully programmable,
> so I can make it do whatever I want”. True. Now, by defining sets of
> possible conditions and actions and letting the user make rules out of
> these, you're basically saying: “Here is a computer. You can program it to
> do whatever you want”. While this might be usable for someone who is a
> programmer (and who's willing to be a programmer when they deal with their
> cell phone), it's not a killer application. It's an absence of
> application; it's rather an interpreter for a programming language in
> which a user can write themself a killer application.
>
> The key to making a phone do what you, I or someone else wants is rather
> in analyzing our requirements and figuring out what parts are constant and
> what are changing. Of course, all people want different things, and the
> same person wants different things at different times. But the number of
> dimensions in the space of all reasonable people's demands is still much
> less than that of the space of all possible rulesets. Only a small subset
> of all possible rules, let alone rulesets, makes any sense at all, while
> the vast majority is nonsensical, such as “When WiFi is available and
> John's phone is nearby, mute all calls”, or “If I have unread SMS on
> Thursday, prefer GPRS”. Analyzing and isolating the axes of user demands
> is much harder than developing a ruleset-driven engine, but at least it
> has a chance of becoming usable.
>
>
_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
