Paul Mossman wrote: > Damian wrote: ... >> 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. > > One criteria I'd like to see considered for the client technology: Can > it be run outside a web browser?
I was thinking about what criteria are important and I do not think that this one is. But read on... > > A richer and more responsive user experience can be delivered in an > application. Take Google Docs as an example. It can come in handy if > you need to open a spreadsheet in an internet café. But I bet your > primary computer has OpenOffice installed on it. Yes: but those 2 are developed using very different technologies. This might be an argument that we need both in-browser and OS native client but not that we should be using the same technology to have both. Also: I find myself to using OO less and less and google docs more and more but that's a different issue. > > I see it as a huge advantage if our user and admin portal could be > cross-packaged as both an browser applet and an application. I see advantage in having various tools usable from different environment. But I do not think we should push for a single technology in which all those tools are implemented. If services offered by 'neoconf' are sufficiently usable and high level it's going to be easy to write the clients in whatever technology is the most appropriate to you target environment. > > >> 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). > > +1 > I am going to start a wiki page to capture this, but from initial investigation this is what I think these are important criteria for a client/user portal technology: - runs in modern browsers without user having to install any plug-ins - allows for communicating with server over RESTful - allows for implementing responsive, rich user interface - is skinable: administrators can change color schemes/logos etc. - allows writing and executing unit test - preferably without having running server - offers no-compilation/minimum compilation deployment during development (unlike with Tapestry/Java - I want to change something and see it in my browser after refreshing a matter of seconds not minutes) I am quite sure at the moment that having chosen technology to be usable outside of the browser is less important than any of the above. But is there anything else I am forgetting about? D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
