Hi devs, Currently XWiki Watch is built as a XWiki application, with no server code, distributable as a xar archive, using only xwiki-web-gwt's XWikiService to communicate with XWiki. While this approach has major advantages from the application accessibility point of view (it can be easily downloaded and installed), the drawback is the big amount of functionality that needs to be implemented on the client side (even if with GWT), with main impact on the application performance (javascript execution in the browser, data transfer, asynchronous calls). I propose to change the current approach and create XWatch server / service and distribute XWatch as a zip / war because: * it improves code performance: less javascript to execute on client side, less network traffic; lighter for the client overall * removing the .xar constraint and distributing watch as zip / war would allow XWatch dependency on plugins / modules versions independent from XE. * some Watch features already need some kind of administration on the hosting machine (emailing press reviews needs a running mail delivery system on the server). As I mentioned already, the only thing we would lose through this change is the possibility of installing XWatch as a simple xar (I am not currently very aware of the amount of users downloading and installing watch as a .xar and not being able to do it otherwise, so if you can give me some info on that...) Since I feel the gains would be above the losses, I am +1 for the switch, WDYT?

Hi devs, Currently XWiki Watch is built as a XWiki application, with no server code, distributable as a xar archive, using only xwiki-web-gwt's XWikiService to communicate with XWiki. While this approach has major advantages from the application accessibility point of view (it can be easily downloaded and installed), the drawback is the big amount of functionality that needs to be implemented on the client side (even if with GWT), with main impact on the application performance (javascript execution in the browser, data transfer, asynchronous calls). I propose to change the current approach and create XWatch server / service and distribute XWatch as a zip / war because: * it improves code performance: less javascript to execute on client side, less network traffic; lighter for the client overall * removing the .xar constraint and distributing watch as zip / war would allow XWatch dependency on plugins / modules versions independent from XE. * some Watch features already need some kind of administration on the hosting machine (emailing press reviews needs a running mail delivery system on the server). As I mentioned already, the only thing we would lose through this change is the possibility of installing XWatch as a simple xar (I am not currently very aware of the amount of users downloading and installing watch as a .xar and not being able to do it otherwise, so if you can give me some info on that...) Since I feel the gains would be above the losses, I am +1 for the switch, WDYT? _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi devs, Currently XWiki Watch is built as a XWiki application, with no server code, distributable as a xar archive, using only xwiki-web-gwt's XWikiService to communicate with XWiki. While this approach has major advantages from the application accessibility point of view (it can be easily downloaded and installed), the drawback is the big amount of functionality that needs to be implemented on the client side (even if with GWT), with main impact on the application performance (javascript execution in the browser, data transfer, asynchronous calls). I propose to change the current approach and create XWatch server / service and distribute XWatch as a zip / war because: * it improves code performance: less javascript to execute on client side, less network traffic; lighter for the client overall * removing the .xar constraint and distributing watch as zip / war would allow XWatch dependency on plugins / modules versions independent from XE. * some Watch features already need some kind of administration on the hosting machine (emailing press reviews needs a running mail delivery system on the server). As I mentioned already, the only thing we would lose through this change is the possibility of installing XWatch as a simple xar (I am not currently very aware of the amount of users downloading and installing watch as a .xar and not being able to do it otherwise, so if you can give me some info on that...) Since I feel the gains would be above the losses, I am +1 for the switch, WDYT? _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs