In Bayonne2 you could just write an entire app in perl, and that of
course does not get compiled until it is executed :). There was several
shared memory structures and files in /var/run/bayonne which offered
interesting and additional information (like about active calls) in the
testing branch. That might be something worth backporting or re-using
in Bayonne 1. But I agree that would be VERY useful to have. I had
seen one other front-end of this type that was done in webmin, but it
did not cover scripts this way. and this one looks nice.
For bayonne2 we could do a number of things potentially. Passing info
like active calls through sunrpc or soap is possible. I could add some
of the shared memory stuff back in also. Whatever you choose to do in
this regard for bayonne1, I will probably try to make a matching plugin
to do for bayonne2 so you can get the same info out of it as well.
Julien Chavanton wrote:
I am building a web front-end to Bayonne1 so that some coworker can
modify the script allocation and script from a web page:
The main feature would be an interface to see active calls + status
variables useable from scripts to help debugging.
Also sending command to script like hangup using the FIFO.
I found bayonne –status a bit limited so I am thinking about
implementing another db status system in driver.cpp.
I guess there is no way to recompile only one script ?
I have working result:
------------------------------------------------------------------------
_______________________________________________
Bayonne-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bayonne-devel
begin:vcard
fn:David Sugar
n:Sugar;David
org:GNU Telephony
adr:;;;;;;USA
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
url:http://www.gnutelephony.org
version:2.1
end:vcard
_______________________________________________
Bayonne-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bayonne-devel
