Russell Bryant e113d36aa4
Merge a set of device state improvements from team/russell/events. ...
The way a device state change propagates is kind of silly, in my opinion. A
device state provider calls a function that indicates that the state of a
device has changed. Then, another thread goes back and calls a callback for
the device state provider to find out what the new state is before it can go
send it off to whoever cares.
I have changed it so that you can include the state that the device has changed
to in the first function call from the device state provider. This removes the
need to have to call the callback, which locks up critical containers to go find
out what the state changed to.
This change set changes the "simple" device state providers to use the new method.
This includes parking, meetme, and SLA.
I have also mostly converted chan_agent in my branch, but still have some more
things to think through before presenting the plan for converting channel drivers
to ensure all of the right events get generated ...
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79027 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-08-10 16:24:11 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
2007-07-20 14:38:36 +00:00
2007-07-16 02:51:56 +00:00
2007-06-20 20:10:19 +00:00
2007-05-24 22:07:50 +00:00
2007-05-24 22:07:50 +00:00
2007-07-30 19:18:24 +00:00
2006-06-05 18:05:53 +00:00
2007-08-06 21:52:30 +00:00
In regards to changes for 9508, expr2 system choking on floating point numbers, I'm adding this update to round out (no pun intended) and make this FP-capable version of the Expr2 stuff interoperate better with previous integer-only usage, by providing Functions syntax, with 20 builtin functions for floating pt to integer conversions, and some general floating point math routines that might commonly be used also. Along with this, I made it so if a function was not a builtin, it will try and find it in the ast_custom_function list, and if found, execute it and collect the results. Thus, you can call system functions like CDR(), CHANNEL(), etc, from within $\[..\] exprs, without having to wrap them in $\{...\} (curly brace) notation. Did a valgrind on the standalone and made sure there's no mem leaks. Looks good. Updated the docs, too.
2007-07-05 18:15:22 +00:00
2007-01-05 23:32:42 +00:00
2006-12-27 18:33:44 +00:00
2006-11-02 18:34:50 +00:00
2006-11-15 20:55:17 +00:00
2007-08-08 19:30:52 +00:00
2007-08-08 21:44:58 +00:00
2007-06-19 17:07:28 +00:00
2006-11-24 14:00:19 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
2007-08-08 21:44:58 +00:00
2005-12-03 19:25:33 +00:00
2007-07-16 02:51:56 +00:00
2007-04-06 21:16:38 +00:00
2006-09-28 13:02:30 +00:00
2007-08-06 16:54:51 +00:00
2007-07-16 02:51:56 +00:00
2007-08-10 16:24:11 +00:00
2007-07-30 20:42:28 +00:00
2005-11-29 18:24:39 +00:00
2006-08-21 02:11:39 +00:00
2006-06-07 17:44:36 +00:00
2007-07-23 14:32:04 +00:00
2005-11-29 18:24:39 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
2006-06-09 20:26:25 +00:00
2007-07-16 02:51:56 +00:00
2007-08-09 17:07:36 +00:00
2007-06-07 23:07:25 +00:00
2007-08-07 23:04:01 +00:00
2007-07-23 14:32:04 +00:00
2007-07-16 02:51:56 +00:00
2007-08-06 19:52:40 +00:00
2007-06-29 20:35:09 +00:00
2007-07-16 02:51:56 +00:00
2007-01-01 20:08:47 +00:00
2005-11-29 18:24:39 +00:00
2007-07-16 02:51:56 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
2007-02-24 20:29:41 +00:00
2007-08-06 16:51:30 +00:00
2007-07-18 19:47:20 +00:00
2007-08-10 15:29:31 +00:00
2007-07-23 14:21:41 +00:00
2007-08-07 22:13:40 +00:00
2005-11-29 18:24:39 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
2007-07-19 23:24:27 +00:00
2007-07-10 15:07:25 +00:00
2007-07-16 02:51:56 +00:00
2007-04-30 16:16:26 +00:00
2007-07-23 14:21:41 +00:00
2006-08-23 21:19:21 +00:00
2007-07-16 18:38:28 +00:00
2006-06-14 14:12:56 +00:00
2005-11-29 18:24:39 +00:00
2005-11-29 18:24:39 +00:00
2007-07-16 02:51:56 +00:00
2007-07-13 16:22:09 +00:00
2007-07-16 02:51:56 +00:00
2006-03-31 10:29:50 +00:00
2006-02-22 22:53:49 +00:00
2007-08-08 19:30:52 +00:00
2006-12-29 06:26:53 +00:00
2007-07-31 16:21:34 +00:00
2006-08-21 02:11:39 +00:00
2007-06-07 23:07:25 +00:00
2007-07-18 19:47:20 +00:00
2007-07-16 02:51:56 +00:00
2006-11-11 02:12:27 +00:00
2007-08-01 18:01:33 +00:00
2007-06-11 21:20:59 +00:00
2005-11-29 18:24:39 +00:00
2007-07-16 02:51:56 +00:00
2007-07-11 20:07:07 +00:00
2006-06-05 18:05:53 +00:00
2005-11-29 18:24:39 +00:00
2007-07-21 14:39:52 +00:00
2007-02-24 20:29:41 +00:00
Russell Bryant
e113d36aa4