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. > > My idea for the moment is like this : > You can define a set of condition to specify the profile. For example : > if at my girl friend house, profile = "Paranoid" > > Then you the application configurations can depend on the profile. e.g : > If profile is "Paranoid", girl_friend_number_2.block_calls = True > > This way, the profile is the link between the conditions set and the > actions set. The number of profiles is not supposed to be too large. > > It is more restrictive that Russel idea, because you can't say : > if time = 600, then play alarm. > > The only way to do so would be : > if time = 600, then profile = "RunAlarm" > if profile is "RunAlarm", then alarm.run = True > > Which is not really useful, you don't want to create one profile for > every events combination you can think of. > > I can see several cases where this way of doing is not the best, but I > still think it is the most suitable for most practical cases. > > -charlie > > Profiles, recipes, rulesets; I think we all talking about the same thing, behaviours. It boils down to detecting a set of conditions and instructing the phone to behaviour in a certain way.
Profiles are an excellent way of describing a group of common phone settings. (settings the call handling services already respect) People are familiar with the concept, they could be described by setting a phone using normal method and saving them. Perhaps if there was a default profile, and we only store differences, the delta, in other profiles, we could have cumulative profiles. That might help with the tedium of setting up every permutation and keep the number of profile down. Profiles are really just a bunch of SET actions. I still see the need for an event broker of sorts, something that will detect conditions and trigger actions. Perhaps the profile switcher (as some else mentioned) could be enhanced for that purpose. An alarm might just be a custom action, just another action. 'Run a shell command' might be the only action we need. Another poster mentioned interacting with his MythTV, one approach might be to configure the MythTV to run web server with some cgi. The phone would just use http to instigate commands. wget? If we had profiles and an event broker, all we need next is some standard way to describe the set of conditions. I'm no hardcore coder, but it seem well within the realms of possibilities. I still favour a scriptable solution, even is it wrapped in UI and machine generated. Regards Matt _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
