Summary:	ASTERISK-04968: [patch] [post 1.2] Web GUI backend for review
Reporter:	Alan Perelman (apman)	Labels:
Date Opened:	2005-09-01 21:43:23	Date Closed:	2011-06-07 14:03:24
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk_webgui.zip
Description:	Here is a GUI backend for the Asterisk server.  A partial front-end is included as well although it'll probably be a few more months until it could be considered commercial quality. The GUI is built around a base and modules.  The idea is that someone can create a module without dealing with parsing, SQL, etc.   This is provided by means of obfuscating the config data.  As far a module is concerned, it doesn’t care if the config data it receives is coming from a conf file, SQL, or via the network or even what syntax it was originally in, since the appropriate medium will format it correctly.  Medium is the name for a module responsible for retrieving and saving config data. The module system is mostly complete.  Modules are loaded on demand and instances are reused to save resources.  It may not sound too glamorous but it works beautifully.  As this project expands, I'm sure the module system will need to be expanded as well. The flat-file medium is complete.  Config files can be parsed to and from an array.  (You can see the structure by doing print_r($medium->get(’extensions’)); for example)  The flat-file medium is always required by the GUI, all others are optional.  I have plans for 2 more mediums in the not so distant future, a MySQL medium for real-time Asterisk config and a "remote" medium which will act as a pass-through of config data between the GUI server and an asterisk server via network (you'd be able to have 1 hosted GUI control several asterisk servers). The front-end modules are called applications.  These can have as simple or as complex as required.  They have access to an application handler which can format the data into proper html.  The details as to what features this handler should have added are very sketchy since that depends on the kinds of modules the community requires.  I'd like to build AJAX support into the handler in the next few months, as this could allow for some killer applications. Important Notes: Due to some major changes I made recently in the backend, much of the front-end has been temporarily removed since it requires updating to the new guidelines.  Therefore all editing menus are missing in this release, so that you can only view the parsed configuration and not change it. The current style/design of the front-end is temporary.  I created it simply to avoid staring at only text while testing.  When the first production quality version of the GUI is complete, it will be completely redesigned and hopefully not as ugly.  It will remain based on XHTML transitional/CSS.  Of course users have the ability to create new styles to fit their preference/environment. I'd like feedback from the community as to help establish the direction of this project.  I experimented with an call routing wizard module (it basically allowed for creating extensions, IVR prompt, setting up users, etc. without dealing with any config code), but came upon a roadblock in that it would work fine if you created and maintained the config using it, but would reek havoc if a user tried to import configs from elsewhere.  So this brings up a question I'd like to hear the community's input on......  should this GUI impose its guidelines and methods onto the user for the sake of ease-of-use?  Or should it be able accommodate the user's intricacies at the expense of a more complex GUI? Requirements: HTTP Server (Apache works, IIS not test but should work also) PHP4 or above It comes with its own set of config files but you can point it to use any you want.
Comments:	By: cleanerx (cleanerx) 2005-10-12 06:07:24 I think it's not wise to display all users in one window. Think about some abstraction layers as you mentioned it above. Asterisk code changes so fast you'll always be in a hurry to update the options to parse correctly. I coudn't see any code of database abstraction. Think of having an storage layer where the stuff is somehow stored and you can configure it. Take a look at Java JDNI to see what I mean. This way you can use any database or file to get information into your interface. This is a starting point and when asterisk features are widely implemented people will cry for this. By: Tilghman Lesher (tilghman) 2005-12-23 16:24:44.000-0600 I suppose this could go into contrib/, unzipped into its individual files. By: Olle Johansson (oej) 2006-01-04 14:12:33.000-0600 Please mail to the -dev mailing list and ask for reviews and tests, thank you. By: Tilghman Lesher (tilghman) 2006-03-06 14:49:43.000-0600 While I agree that this is useful, it really doesn't belong in the Asterisk distribution.  I encourage you to continue to develop this and to distribute it, but its presence isn't appropriate within Asterisk itself.  You might consider posting a page for this on the Wiki, along with other contributed software.