9 Aug
2008
9 Aug
'08
2:40 p.m.
On Aug 7, 2008, at 11:27 AM, Jerome Velociter wrote:
Sergiu Dumitriu wrote:
+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
Anca Paula Luca wrote:
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. 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...