On Aug 7, 2008, at 11:27 AM, Jerome Velociter wrote:
Sergiu Dumitriu wrote:
Anca Paula Luca wrote:
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?
+1
All the other products have java parts, so if you manage to keep the extra code as plugins, then turning an existing XE installation into a Watch would be as hard as it is for the other products. And there are people who manually turned XE into XEM, so it's not impossible. Of course, the documentation would need to be improved...
Not exactly the same as for other products, since for GWT service you need to add a entry point in web.xml. (Unless we can devise a way of having xwiki-web-gwt loading other services and dispatching requests to them, then we could use the already existing /XWikiService entry point. Though, I don't know if it's realizable/easy to do). But even if one have to add an entry to web.xml, I don't think it is stopper, so I'm +1 anyway.
+1. There are ways to merge 2 web.xml in the build (using a cargo maven plugin for example, I don't have the url at hand but it's easy to find it). OTOH, and even better, we could also think about having a single generic servlet and use an identifier in the url path to differentiate the different services. Then we could use the xwiki-action module to dispatch to the correct actions to execute. In this manner we'll transform a web problem into a component one. WDYT? Thanks -Vincent