From: Matt D. <mda...@se...> - 2003-07-14 01:36:22
|
Aloha, I trust everyone had a good weekend! I have uploaded a zipped file of a PDF that shows the features of ver = 1.0. Click the download by the linuxvm, then click on = Visio_call_flow.zip. Of course from there we need to drill down. I will have the database fields by this evening or tomorrow. How does Wednesday at 5PM sound for a meeting at my office? We can = decide on the objects and how the email synchronization will be done. I will have the box loaded with Debian and the card installed. I have = ordered 5 more cards and we can install another one in a FreeBSD box = when they come in. Aloha, Matt |
From: Dean T. <de...@ha...> - 2003-07-14 20:42:15
|
> How does Wednesday at 5PM sound for a meeting at my office?=A0 We can=20= > decide on the objects and how the email synchronization will be done. Wednesday is doable for me. > I will have the box loaded with Debian and the card installed.=A0 I = have=20 > ordered 5 more cards and we can install another one in a FreeBSD box=20= > when they come in. The FreeBSD Voicetronix drivers are interesting to me since their=20 existence implies that porting them to MacOS X may not be hard :) -dean= |
From: Matthew J. D. <mda...@se...> - 2003-07-14 20:45:10
|
Dean, That would be cool to see it running on a Mac. I wonder what telephony = solutions there are for a Mac? -Matt ----- Original Message -----=20 From: Dean Takemori=20 To: lin...@so...=20 Sent: Monday, July 14, 2003 10:38 AM Subject: Re: [Linuxvm-dev] Features in 1.0 How does Wednesday at 5PM sound for a meeting at my office? We can = decide on the objects and how the email synchronization will be done. Wednesday is doable for me. I will have the box loaded with Debian and the card installed. I = have ordered 5 more cards and we can install another one in a FreeBSD = box when they come in. The FreeBSD Voicetronix drivers are interesting to me since their = existence implies that=20 porting them to MacOS X may not be hard :) -dean |
From: Kevin E. <ke...@en...> - 2003-07-14 21:03:42
|
Wednesday is fine for me too.. i have some ideas about how the software should be structured, i'll try to formalize them a little and send them on later today. One concern i have is how we can test this on our home machines. it'd be nice to write a package of stubs that more or less emulate the behavior of this ct-server so that the application logic can be coded without actually having the cards installed on the machine. this might be a good question to ask Voicetronix. also, matt, can u post the little test perl program u showed us on friday... k >> How does Wednesday at 5PM sound for a meeting at my office? We can >> decide on the objects and how the email synchronization will be done. > > Wednesday is doable for me. > >> I will have the box loaded with Debian and the card installed. I have >> ordered 5 more cards and we can install another one in a FreeBSD box >> when they come in. > > The FreeBSD Voicetronix drivers are interesting to me since their > existence implies that > porting them to MacOS X may not be hard :) > > -dean |
From: Matthew J. D. <mda...@se...> - 2003-07-14 21:21:14
|
Kevin, > Wednesday is fine for me too.. i have some ideas about how the software > should be structured, i'll try to formalize them a little and send them on > later today. That is great. There are other things going on, but that is the call flow. We can look at the other issues on Wednesday. One concern i have is how we can test this on our home > machines. it'd be nice to write a package of stubs that more or less > emulate the behavior of this ct-server so that the application logic can > be coded without actually having the cards installed on the machine. this > might be a good question to ask Voicetronix. I was thinking to put our test box outside of our firewall and allow eveyone to ssh into it. everyone would be assigned a port, 1200, 1201, 1202, etc. When I as starting my script I will use "./vmail.pl -p 1203", Dean would use "./vmail.pl -p 1202" etc. That will keep use from conflicting with each other. I can give a direct line to each port, that will allow you to call in from anywhere and test. Does that do what you want? > also, matt, can u post the little test perl program u showed us on friday... I put it on the Sourceforge website, look at the file releases, I gave it version 0.01.001 -Matt |
From: Dean T. <de...@ha...> - 2003-07-14 21:47:21
|
On Monday, Jul 14, 2003, at 11:21 Pacific/Honolulu, Matthew John Darnell wrote: > Kevin, > >> Wednesday is fine for me too.. i have some ideas about how the >> software >> should be structured, i'll try to formalize them a little and send >> them on >> later today. > > That is great. There are other things going on, but that is the call > flow. > We can look at the other issues on Wednesday. Note that the O'Reilly Perl Cookbook has example code on how to write a pre-forking master server. I was thinking along those lines myself. -dean |
From: Vince H. <li...@ml...> - 2003-07-15 05:29:20
|
On Mon, Jul 14, 2003 at 11:40:18AM -1000, Dean Takemori wrote: > Note that the O'Reilly Perl Cookbook has example code on how to > write a pre-forking master server. I was thinking along those > lines myself. Pre-forking should be the approach if there are plans to be any kind of load. Perl is a memory beast, especially if we get OO crazy. Just to throw it out there, long lasting perl daemons leak memory. It is something to be aware of, but probably not something we should worry about just yet. -Vince |
From: Matthew J. D. <mda...@se...> - 2003-07-15 06:48:57
|
> Just to throw it out there, long lasting perl daemons leak > memory. It is something to be aware of, but probably not > something we should worry about just yet. A weekly/nightly reboot would not be a horrible thing. Very little use from 8PM - 6AM on a voiecmail, next to none on a Sunday night. -Matt |
From: Dean T. <de...@ha...> - 2003-07-15 23:07:20
|
On Monday, Jul 14, 2003, at 20:48 Pacific/Honolulu, Matthew John Darnell wrote: >> Just to throw it out there, long lasting perl daemons leak >> memory. It is something to be aware of, but probably not >> something we should worry about just yet. > > A weekly/nightly reboot would not be a horrible thing. Very little > use from > 8PM - 6AM on a voiecmail, next to none on a Sunday night. I dug up some old TCP server/client perl code I wrote a few years back and merged it with the sample preforking server code from the cookbook. It's a _mostly_ working framework at this point, but missing the Voicemail functionality of course. On startup this "operator" script forks a copy of itself to bind to port 1198, another on 1199 and one each on port 1200 on up until a MAXPORTS condition is met. If bound to port 1198, the child can perform 'management' tasks. The 1199 port is an "are you alive" port that's left over from my previous project - it may or may not be useful. Note that this was more an exercise in re-familiarizing myself with perl TCP sockets than an attempt at any real production code. It is debatable whether this approach or a run-one-script-per-port approach is better. This approach has the disadvantage of building all the functionality into one big script. There may be an advantage in that the parent process can act as a nanny for all the children, reforking a new one if a child dies or automagically killing them if they live too long. -dean |
From: Matthew J. D. <mda...@se...> - 2003-07-16 00:30:06
|
> This approach has the disadvantage of building all the functionality > into one > big script. There may be an advantage in that the parent process can > act > as a nanny for all the children, reforking a new one if a child dies or > automagically killing them if they live too long. Dean, One thing to remember is the tasks need to do other things beside answer calls. i.e. If someone looks at all their messages on the computer the message waiting light needs to go off their phone. Some process that is doing the syncronization will have to tell one of the threads they need to go off hook and dial the MWI code, or to notify someone on their pager. We need to devise a way for one of the scripts to be able to break out of its loop while it is waiting for a call. It could be as simple as they all continualy check a test file for something to do, they would delete the entry so no other scripts will duplicate it, if successful it would write it to a log, on a failure it would write it back to the "jobs" file/database. It could also be a mother script passing out assignment via tcp-ip. Something to think about. -Matt |