astweb-users

RE: [Astweb-users] Introduction, Status and Plans

[Jamie C. <jam...@po...>]

I did think about doing that also, but only after I wrote the email.  Thanx=
 for the code too.  I'll look at it tomorrow (it's almost Beer 0'clock here=
).
It would be a much nicer way and the is definitely a way to get PHP to do i=
t.  PHP has socket functions built in and are super easy to use from what I=
 can see.

<-- J


 -----Original Message-----
From: 	WipeOut [mailto:wip...@ly...]=20
Sent:	Friday, 3 October 2003 17:07
To:	ast...@li...
Subject:	Re: [Astweb-users] Introduction, Status and Plans

 << File: asterisk.reload >> Jamie Carl wrote:

>I may also have some work started on signalling the Asterisk server to rel=
oad the configs, cause I'm curious how we're going to pull this part off my=
self (will start with a command line reload, if you don't know what I'm tal=
king about, never mind :-) ).
>
> =20
>
Have you looked at phpconfig??, they use perl to connect to the Asterisk=20
manager interface and send a restart command.. Works well and is quite=20
simple once you look at the code.. :)

I have attached the file.. I wonder if there is not a war to get PHP to=20
do this..

Later..



**********************************************************************
PowerTel Limited, winners of
Best Corporate/Wholesale Broadband Initiative, Australian Telecom Awards 20=
02
Broadband Wholesale Carrier of the year, CommsWorld Telecomms Awards 2001
Best Emerging Telco, Australian Telecom Awards 2001

**********************************************************************
This email (including all attachments) is intended solely for the named
addressee. It is confidential and may contain commercially sensitive
information. If you receive it in error, please let us know by reply email,
delete it from your system and destroy any copies.

This email is also subject to copyright. No part of it should be reproduced,
adapted or transmitted without the prior written consent of the copyright o=
wner.

Emails may be interfered with, may contain computer viruses or other defects
and may not be successfully replicated on other systems. We give no
warranties in relation to these matters. If you have any doubts about
the authenticity of an email purportedly sent by us, please contact us
immediately.

**********************************************************************

Re: [Astweb-users] Introduction, Status and Plans

[WipeOut <wip...@ly...>]

Tjardick van der Kraan wrote:

>Ok sorry for the mssing threading, but i messed up my procmail rules on this
>list so i lost my own mail and wipe out's reply so just pasting it in there
>to fake it all :)
>
No problem.. :)

>Ok well ive been using PHP AdoDB quite alot, and while still early in the
>project it might be good to take a look at that now before to many sql stuff
>is allready written and needs to be redone.
>  
>
Yes I think thats a good suggestion, I have used other apps that made 
use of ADODB and it worked quite well..

Somthing else we should look at is standardising some sort of interface 
structure and module navigation.. ( I think Jamie said he is working on 
this already)

Having a standard page structure will make the whole app more user 
friendly and will reduce effort because we could simply create header 
and footer includes just adding entries for new modules and menu items..

My suggestion would be to have a "tabbed" structure accross the top to 
get into the various modules, and then either a row of "sub-tabs" for 
items relating to that module or a secondary menu down the left side..

This structure may also help when we get to a point of implimenting 
access controls, different users or groups of users would have access to 
particular modules only.. but thats getting a little ahead of ourselves 
now.. :)

Thoughts?

Later..

Re: [Astweb-users] Introduction, Status and Plans

[Chris T. <ct...@da...>]

> >Ok well ive been using PHP AdoDB quite alot, and while still early in the
> >project it might be good to take a look at that now before to many sql stuff
> >is allready written and needs to be redone.
> >  
> >
> Yes I think thats a good suggestion, I have used other apps that made 
> use of ADODB and it worked quite well..

Well I couldn't actually get to the adodb page so I am not sure, but it
sounds like Perl's DBI, which I love.  I think the set of things that
are needed for something like this could easily be done via an ODBC
interface so as to make it database independent, we're not talking about
a large transactionally heavy workload here.

> My suggestion would be to have a "tabbed" structure accross the top to 
> get into the various modules, and then either a row of "sub-tabs" for 
> items relating to that module or a secondary menu down the left side..
> 
I agree, tabs have started to become familiar for people on both the
desktop application side and web application side.  As for those people
that need a "desktop" application, this could easily be wrapped in to a
highly stripped down mozilla client and the pages served from localhost.
> This structure may also help when we get to a point of implimenting 
> access controls, different users or groups of users would have access to 
> particular modules only.. but thats getting a little ahead of ourselves 
> now.. :)
> 
I personally feel like those should be design concepts from the
beginning.  As long as everyone understands where it's headed, there is
no need to implement them immediately but consideration needs to be made
for them throughout.

I think Jamie's project of starting with something that is useful to
"Management" type people and relatively siloed is good.  The core of the
configuration system is going to be handling extensions with almost
everything else in "User" world handled based on the creation of an
extension.

Chris Tooley

Re: [Astweb-users] Introduction, Status and Plans

[Chris T. <ch...@nt...>]

> >Ok well ive been using PHP AdoDB quite alot, and while still early in the
> >project it might be good to take a look at that now before to many sql stuff
> >is allready written and needs to be redone.
> >  
> >
> Yes I think thats a good suggestion, I have used other apps that made 
> use of ADODB and it worked quite well..

Well I couldn't actually get to the adodb page so I am not sure, but it
sounds like Perl's DBI, which I love.  I think the set of things that
are needed for something like this could easily be done via an ODBC
interface so as to make it database independent, we're not talking about
a large transactionally heavy workload here.

> My suggestion would be to have a "tabbed" structure accross the top to 
> get into the various modules, and then either a row of "sub-tabs" for 
> items relating to that module or a secondary menu down the left side..
> 
I agree, tabs have started to become familiar for people on both the
desktop application side and web application side.  As for those people
that need a "desktop" application, this could easily be wrapped in to a
highly stripped down mozilla client and the pages served from localhost.
> This structure may also help when we get to a point of implimenting 
> access controls, different users or groups of users would have access to 
> particular modules only.. but thats getting a little ahead of ourselves 
> now.. :)
> 
I personally feel like those should be design concepts from the
beginning.  As long as everyone understands where it's headed, there is
no need to implement them immediately but consideration needs to be made
for them throughout.

I think Jamie's project of starting with something that is useful to
"Management" type people and relatively siloed is good.  The core of the
configuration system is going to be handling extensions with almost
everything else in "User" world handled based on the creation of an
extension.

Chris Tooley
-- 
Chris Tooley
Networking Technologies Resource Center
8650 Spicewood Springs Rd, Suite 105
Austin, Texas 78759
Office Phone:  250-8985               Office Fax:    250-5909
Mobile Phone:  659-2498               Email Add:     ch...@nt...