I am trying to start discussion on sipXconfig changes post 4.0 release. With the ability to add phone, gateway and services plugins sipXconfig is a flexible tool that can be used to manage diverse set devices and services. However it only offers a limited set of external interfaces: WEB UI and SOAP. To make things worse current SOAP interfaces are not complete and existing ones are not easy to use. Also current UI does not do that best job presenting the wealth of features that we have implemented.
As you know just by looking at the source structure Current sipXconfig can be roughly divided in 2 parts: 'neoconf' and 'web' modules. 'neoconf' does bulk of the interesting work. It maintains settings database (values of specific parameters for device and services), user database. It has an extensible plug-ins based architecture that allows adding external device and service plug-ins. It's based on a healthy foundation of IOC container (spring) and ORM (mapper). It's well tested and easy to work with. On top of the neoconf we have web module which is currently responsible for providing both SOAP services and HTML client (admin + user portal). We use jetty as a servlet container, and Tapestry (4.1) as an UI library. We struggled to improve user experience in Tapestry (check the new conference UI). But it proves difficult 4.x is not actively maintained any more. Upgrade to Tapestry 5 is extremely costly and does not offer the change I am looking for. Judging by what one can see on the WEB these days the era of your traditional WEB applications (based on render/submit/rewind/render cycles) is drawing to an end. Browsers are now perfectly capable of running quite intricate applications: editors, spreadsheets, photo tools. We do not need anything that complicated to build a useful UI: but users expect much more than we offer now. Our user portal and later also admin portal should run inside of the browser exchanging not HTML, but data with the 'neoconf' based server. Most modern WEB accessible services use RESTful (over HTTP(s)) as a protocol in browser<->server interactions and I am proposing we do the same. REST is simple to implement, well documented, standard based and usable from any type of client and programming language without costly specialized libraries. I hope, that if our UI is using the same protocol that we offer as an external interface, we will be extending and testing this interface regularly (unlike SOAP). And hopefully that will enable others to create useful sipXconfig clients in whatever technology it makes sense to them. It should lead to sipXconfig clients running on IPhone, Android and various widget containers etc. Also many non-UI tools - for example related to exporting/importing user data will become easily implementable. I believe we could gradually transition to the model I attempted to describe above: by adding more REST services, rewriting user portal, adding more interactive features to admin portal. There are some technical questions that would be good to tackle here: - do we need to use new or update current libraries for REST (we use RESTlet at the moment, is there anything we need to evaluate out there?) - what client technology makes sense - I am partial to direct or generated javascript since this is what browsers are running natively, is there anything else we should look at? - if it is javascript - what library if any? GWT, pyjs, scriptaculous /dojo, jquery - others? I'd like to use a library that let's me to write application and not something that is used to sprinkle some Ajax magic on static HTML. We should probably do what we did when selecting Tapestry: choose 2-3 contenders, write an example page and compare experience. Feedback appreciated. Damian PS. If you are sipXconfig contributor: some books worth reading... JavaScript: The Good Parts, Douglas Crockford http://oreilly.com/catalog/9780596517748/ RESTful Web Services, Leonard Richardson, Sam Ruby http://oreilly.com/catalog/9780596529260/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
