It would be good to make sure that it's easy to have prolog or some
other rule based system autogenerate and interface to the small domain
specific language. I think the way it would work is prolog would use
some event handlers to maintain a table of facts that the DSL would then
use as its
Scott wrote:
I just found this inference engine.
http://ruleby.org/wiki/Ruleby
I working on a Rails project think Ruby is a great language to work
with. And Ruby is pretty small..
A bit too many layers there for my taste. :)
A domain specific rules language implemented in ruby embedded
Tilman Baumann wrote:
Scott wrote:
I just found this inference engine.
http://ruleby.org/wiki/Ruleby
I working on a Rails project think Ruby is a great language to work
with. And Ruby is pretty small..
A bit too many layers there for my taste. :)
A domain specific rules
Hi,
I'm one of the GSoC students and work on the answering machine. I
already use this concept in my project and it uses modules so it might
be possible to extend it to fit your needs. It's implemented in vala so
you can use all GLib functionality and more. As far as you can create
vala bindings
On Wed, Jul 23, 2008 at 6:41 AM, Frederik Sdun
[EMAIL PROTECTED] wrote:
Hi,
I'm one of the GSoC students and work on the answering machine. I
already use this concept in my project and it uses modules so it might
be possible to extend it to fit your needs. It's implemented in vala so
you can
I fell out of this discussion for a while, but I'd much rather see a
very simple C API that delivers events from DBUS with bindings for
python / your favorite language. The event system and programming model
(rule based, prolog, python, ...) should be completely separate modules.
That way,
Russell Sears [EMAIL PROTECTED] writes:
I fell out of this discussion for a while, but I'd much rather see a
very simple C API that delivers events from DBUS with bindings for
python / your favorite language. The event system and programming model
(rule based, prolog, python, ...)
I'd like to see a diagram showing how you envisage this fitting together.
Somethings like :
App1=D=[event handler, current states]=[rules
engine]=[rules]=[rules gui]
App2=B
App3=U
App4=S
I'm not clear on the existing role or use of DBUS, are existing apps
(gsmd, gps, mplayer, contacts, clock,
If GPS position is going to be a phone answering rule you would have to
have the GPS sub system running all the time. It can't wake from sleep
and acquire a position soon enough go be part of the decision. Not sure
what that will do to battery life.
Scot
signature.asc
Description: OpenPGP
Scott Derrick wrote:
If GPS position is going to be a phone answering rule you would have
to have the GPS sub system running all the time. It can't wake from
sleep and acquire a position soon enough go be part of the decision.
Not sure what that will do to battery life.
Scot
That's a
Scott Derrick, 2008-07-20 06:45:44 -0600 :
If GPS position is going to be a phone answering rule you would have
to have the GPS sub system running all the time. It can't wake from
sleep and acquire a position soon enough go be part of the
decision. Not sure what that will do to battery life.
It may be possible to use GSM call towers to give a good enough location
for these rules.
a gsm cell is usually much bigger than most restaurants -- and gps might
not be available inhouse.
btw: a rule that analyses calendar entries and depending of the character
of the appointment disables
On Sun, July 20, 2008 3:28 pm, arne anka wrote:
a gsm cell is usually much bigger than most restaurants -- and gps might
not be available inhouse.
True, but you can still use the GSM cell to determine that you are not in
the restaurants, because you are in a different cell on the other side of
I thought about it awhile and decided that you could have the GPS engine
get a fix every 5 minutes or some user adjustable time frame and use the
last known fix. 99% of the time it would probably be close enough.
Scott
matt joyce wrote:
Scott Derrick wrote:
If GPS position is going to be a
Or, perhaps use GSM triangulation to trigger GSP fix acquisition.
Scott Derrick wrote:
I thought about it awhile and decided that you could have the GPS
engine get a fix every 5 minutes or some user adjustable time frame
and use the last known fix. 99% of the time it would probably be
arne anka wrote:
It may be possible to use GSM call towers to give a good enough location
for these rules.
a gsm cell is usually much bigger than most restaurants -- and gps might
not be available inhouse.
btw: a rule that analyses calendar entries and depending of the character
Problem there is the rule based engine is trying to decide to answer the
call, put it to voice mail, vibrate, ring loud, etc... Waiting 30-60
seconds for a cold start fix from the GPS is too long.
Scott
matt joyce wrote:
Or, perhaps use GSM triangulation to trigger GSP fix acquisition.
Sorry, I should have been clearer.
What I meant was, if the rule engine/event broker has geo defendant rules,
it could use GSM towers to ascertain if a GPS fix is required.
This (or other checks, such as calendar, time) can happen prior to any
voice/message events occurring, gsmd would just check
matt joyce [EMAIL PROTECTED] writes:
Ryan, what approach have your efforts taken already?
Any interesting insights to the problem?
Matt
My efforts as far as applying my inference engine to the OpenMoko platform
basically consist of a few ideas rattling around in my head -- nothing
Am So 20. Juli 2008 schrieb Scott Derrick:
Problem there is the rule based engine is trying to decide to answer the
call, put it to voice mail, vibrate, ring loud, etc... Waiting 30-60
seconds for a cold start fix from the GPS is too long.
But you can listen to mic to determine on ambient
On Mon, Jul 21, 2008 at 11:08 AM, Ryan Meador [EMAIL PROTECTED]
wrote:
matt joyce [EMAIL PROTECTED] writes:
Ryan, what approach have your efforts taken already?
Any interesting insights to the problem?
Matt
My efforts as far as applying my inference engine to the OpenMoko platform
2008/7/20 Ryan Meador [EMAIL PROTECTED]:
I think it's important that we use an existing general-purpose platform such
as
Prolog (at least, it's about as general purpose as logic programming gets...).
I would favor Rhino.DSL, simply because I know it integrates well with
a language with dbus
Steven Kurylo [EMAIL PROTECTED] writes:
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
Ryan Meador wrote:
Steven Kurylo [EMAIL PROTECTED] writes:
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,
Hi,
I'm one of the GSoC students and work on the answering machine. I
already use this concept in my project and it uses modules so it might
be possible to extend it to fit your needs. It's implemented in vala so
you can use all GLib functionality and more. As far as you can create
vala bindings
On Thu, Jul 17, 2008 at 5:01 PM, matt joyce [EMAIL PROTECTED] wrote:
I have always wanted many more features on my phone, than any phone I've
owned has provided.
I expect the majority of people who are excited about Openmoko have
similar day dreams.
Exactly. I have been thinking about this
Alexey Feldgendler:
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
matt joyce wrote, On 18/07/08 00:01:
I have always wanted many more features on my phone, than any phone I've
owned has provided.
I expect the majority of people who are excited about Openmoko have
similar day dreams.
Absolutely. It was one of the reasons I wanted to go for a phone
Guillaume Chereau wrote:
This is one of the thing I am planning to add in the framework (FSO
project), although for the moment we don't focus on it too much.
I agree with Alexey as well, the danger is to create something so
configurable, that at the end your setting become a python script.
However, I would've thought that if every application can generate and
consume 'events', then all that is needed in your policy app is the
ability to look for combinations of events (and/or states?) and generate
new events that other apps can pick up? Is that what you were thinking.
I have always wanted many more features on my phone, than any phone I've
owned has provided.
I expect the majority of people who are excited about Openmoko have
similar day dreams.
I'd like to propose a rule based policy engine.
In essence this would be an event based system, a service that
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
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
On Fri, Jul 18, 2008 at 9:59 AM, Alexey Feldgendler [EMAIL PROTECTED]
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
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
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
On Fri, Jul 18, 2008 at 11:55 AM, Steven Kurylo [EMAIL PROTECTED]
wrote:
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,
This is one of the thing I am planning to add in the framework (FSO
project), although for the moment we don't focus on it too much.
I agree with Alexey as well, the danger is to create something so
configurable, that at the end your setting become a python script.
My idea for the moment is like
38 matches
Mail list logo
