On Sun, 2009-04-26 at 21:45 +0200, Paweł Pierścionek wrote: > On 2009-04-26, at 20:54, Scott Lawrence wrote: > > > > >> It was "easy" to manage processes in 3.10 so my initial prototype was > >> a single RPM with post-install script disabling all relevant original > >> processes and enabling my own. > >> But I have no idea how to approach 4.0 > > > > It's actually even easier now. You need to create a new-style process > > description xml file that describes each of your processes and tells > > the > > sipXsupervisor what the process needs and how to control it. > > But how do I turn services on/off ?
Ultimately, that is the job of sipXconfig - it is accomplished by an XML RPC call to sipXsupervisor, documented here: http://sipxecs.sipfoundry.org/doc/sipxsupervisor/class_proc_mgmt_rpc_start.html That call can be made for testing purposes using the 'sipxproc' rpc client command. > > How large is the delta, and what version have you been using as the > > base > > for your development? > > It's not based on sipXacd code. That's not what I meant... I was referring to the general framework (including the supervisor, etc). > 3k lines of memory leaking PHP code at Your service. :( > > This is just proof of concept that with some bugs ironed out FS can be > the base for ACD replacement in sipXecs. > Once our FS JTAPI is finished and FS has all SIP/TCP and SIP/REFER > bugs fixed we'll code our ACD it in Java and make it a fully multi- > site / load-balancing cluster. > > I opted for new code as I could not get around stability issues of the > current one. Also wanted some extra features for the installations we > are doing this year. > > My goal was to replicate 100% of the functions of the current ACD. > Apart from being able to put it on a distributed server or change the > default SIP and/or XML/RPC ports my code simulates all features of the > current ACD. > > Some things behave differently - eg always on agents show as always > logged in, one cannot log out if marked as always logged-in. > Presence is persistent across "reboots". There are no actual reloads > needed - new config comes online as soon as one clicks on "activate" > in sipXconfig. > Lines & queues have priorities. > > sipXconfig-agent /reported serves data directly from Postgres database > - no lag/ no memory hungry log processing. > > The ACD server is a single threaded Finite State Machine that > processes FS events. > > So generally not something that is an evolution of current product but > a proof that revolution is possible and something that will allow me > to build 500 seat custom ACD setups this year. Very intriguing Pawel. It would be helpful if you had a writeup of the functionality from an end-user/administrator point of view. Certainly the additions of transfer capability and HA would be very welcome. Do you have any idea how much time/effort it will take to get from "leaky PHP" prototype to production-ready? I think the thing to do is probably to get you a branch that you can check this in on, and someone who can help you with the process management issues. I'll see if we can rustle something up.... _______________________________________________ sipx-dev mailing list sipx-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
