Time Conditons Suggested Changes

I would like to start a discussion wrt re-architecting Time Condions. I proposed the following here:

http://www.freepbx.org/wiki/TimeConditionsChange

so in addition to this disucssion, valuable additions can be added there. I’ll repeat the above wiki page posting here to kick off discussion:

Wiki Page:

We should re-architect time conditions such that it becomes an ‘abstract’ set of timeconditions with no actions associated with it. Then modules that want to include time conditinions can poplulate a menu obtained by a method supplied by the timecondtions module.

The first step would be to separate the ‘goto’ from the current ‘timeconditions’ and make a new page/module to create the goto conditions that pulls from this class. Then other modules can use the same time conditions for other purposes.

This is analogous to how some SOHO routers I’ve looked at work. You setup time conditions that can be used in menus like internet availability, when port forwarding should be restricted, etc. It provides for one place to setup the fairly ‘complex’ time condition menu.

An example of where this could be immediately applied is outbound-allroutes. Today the routes get generated as such:

[code:1]
[outbound-allroutes]
include => outbound-allroutes-custom
include => outrt-001-Emergency
include => outrt-002-Local
include => outrt-003-LongInternational
[/code:1]
as an example. With a very minor tweak, using the proposed timeconditons class, you might create a timeconditions that looks like the following, (say you had free PSTN calls on weekends…)

[code:1]
[outbound-allroutes]
include => outbound-allroutes-custom
include => outrt-001-Emergency
include => outrt-002-Local
include => outrt-003-LongInternational||mon-fri||*
include => outrt-004-PSTNLongInternational||sat-sun||*
[/code:1]
This is an example of an ‘easy win’ since the format of oubound routing already lends itself to a structure that could quickly adopt this. Plenty of other modules could adopt time conditions in various creative ways if they could simply include a class method which gives them the pulldown menu of existing timeconditons to choose from, and the associated methods in functions to retrieve and include the info in the generated dialplans.

On Saturday 06 May 2006 11:44, p_lindheimer wrote:

[quote] I would like to start a discussion wrt re-architecting Time Condions. I
proposed the following here:

http://www.freepbx.org/wiki/TimeConditionsChange

so in addition to this disucssion, valuable additions can be added there.
I’ll repeat the above wiki page posting here to kick off discussion:

Wiki Page:

We should re-architect time conditions such that it becomes an 'abstract’
set of timeconditions with no actions associated with it. Then modules that
want to include time conditinions can poplulate a menu obtained by a method
supplied by the timecondtions module.

The first step would be to separate the ‘goto’ from the current
’timeconditions’ and make a new page/module to create the goto conditions
that pulls from this class. Then other modules can use the same time
conditions for other purposes.

This is analogous to how some SOHO routers I’ve looked at work. You setup
time conditions that can be used in menus like internet availability, when
port forwarding should be restricted, etc. It provides for one place to
setup the fairly ‘complex’ time condition menu.

An example of where this could be immediately applied is
outbound-allroutes. Today the routes get generated as such:

[outbound-allroutes]
include => outbound-allroutes-custom
include => outrt-001-Emergency
include => outrt-002-Local
include => outrt-003-LongInternational

as an example. With a very minor tweak, using the proposed timeconditons
class, you might create a timeconditions that looks like the following,
(say you had free PSTN calls on weekends…)

[outbound-allroutes]
include => outbound-allroutes-custom
include => outrt-001-Emergency
include => outrt-002-Local
include => outrt-003-LongInternational||mon-fri||*
include => outrt-004-PSTNLongInternational||sat-sun||*
[/quote]
Hmm, this is an interesting approach. I don’t think I completely understand
how it would work. How would other parts of the dialplan handle these time
conditions, and would the same work for a queue (for example)?

Ryan


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642


Amportal-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amportal-devel

Post generated using Mail2Forum (http://www.mail2forum.com)

Ryan,

the idea is that you simply create a list of named time conditions. For example:
[list]
WeekDayWorkHours
SatWorkHours
SunWorkHours
FreeNightsLongDistance
[/list:u]
These simply become named timeframes that other modules can access. This keeps the ‘complicated’ set of menu choices to create a named timeframe in one place, and allows any module that needs to have such times provide a simple pulldown list just like you do for destinations in places like ringgroups or follow-me. Now any module can present a simple menu, and behind the scenes access all the time information in providing functionality.

So for example, you could add a menu item on the outbound routing page that says ‘restrict this route to the following times.’ The default would be ‘all times’ 'but you could then choose any timeframe that was defined in the time module.

make sense?

p