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...
--
Sergiu Dumitriu
http://purl.org/net/sergiu/