[xwiki-devs] Back to the future of XWiki !

jstoldt j.stoldt at gmx.net
Wed Mar 9 09:49:41 UTC 2011

Hi Vincent,

Regarding the download page, this looks like really nice progress. Listing
consulting firms there is also a nice and handy approach. Not listing
non-contributing firms is a very legit and understandable thing from a
development community POV. However, I was actually not pointing at how it is
hard to find supporting firms, I was much more pointing at how few there are
around and how many support Confluence. What XWiki should try, one way or
another, is to make more companies support XWiki. The major problems here
are that many consulting firms do not have a lot of man-power so they have
to focus on a smaller portfolio to keep up with the work load. Also, it is
self-explanatory that more consultants and consulting firm will cause the
market to be a lot more competitive. Still, I believe that if more support
is available more customers will use it, more feedback and requests will be
generated toward those consultants and, hopefully, they will actually start
contributing in public.

About the whole VM business, I understand that this is getting ever more
important these days but I am not a real fan of the ready to go VM. I
considered this in my internship for another software I looked into and then
figured out the only two ways to run the VM was to use either a commercial
version of some VM software or to go with the VMWare Player which didn't
really sound appropriate for production either. In the end I installed XWiki
on a virtual instance of MS Windows Server 2008 R2 with a MS SQL Server 2008
R2 database within the cloud of the IT company that manages the whole IT
business for the company. This setup would at least only require the web
server/servlet container and XWiki WAR to be maintained from somebody other
than the IT folks. The point being that VMs are nice in a small environment
where the structures are small and clear or even just local. But as soon as
it goes into larger business there is bound to be more trouble than just
upload and run a pre-built VM.

You are right that you need feedback from technical users on what
configurations and so forth and I tried giving and adding such information
over the past few months. However, my point was that it should simply be
easier to use. I discussed this with Caleb last night and he had this idea
about some sort of wizard which sounds like exactly the thing I was thinking
about. Collect the necessary information on configurations and such from the
user and build it into a tiny tool that helps configuring a ready-to-use
productive environment.

The Extension Manager sounds really nice and I believe you will be able to
make great things happen with it. Still, this seems to be more of a top
level back-end framework that will ease integration with other software,
features and so forth. What I was talking about, however, was that XWiki
could greatly benefit from working more closely with other de facto company
standards. I already mentioned MS Sharepoint Server integration, although
admittedly, I never got around checking out what Atlassian offers there in
detail. Another thing I could think of would be to use XWiki somehow more
closely along with Lotus Notes. For instance, my former company had some
workflows which were spread among SAP and Lotus Notes and I believe there
are use cases where an integration with XWiki would be benefitial, like
reusing data stored in a Lotus Notes database and view it in a nicer fashion
in XWiki. IMO a lot of engineering and design departments can make great use
of wiki software in general but what they need even more nowadays is a
Product Data Management system. So why not see if there are ways to
integrate XWiki in PTC Windchill, Dassault Systemes ENOVIA, SAP PLM or
Siemens PLM Software? This is obviously very technical with a very focused
market but I believe these could be great selling points, especially if
patronages or collaborations with some of the major PDM/PLM vendors can be

About updating, what I would really love to see would be sort of update
packages. I know this will increase the workload for the release manager but
I think creating minimal packages that only update necessities in an
automated fashion will lower the threshold for people being comfortable with
updating even if they have little idea of what they are doing. Also, a
stricter separation between setting storage pages and code pages would be
neat. I do not know if this is possible but what I could imagine to be great
would be to stop shipping documents like WebPreferences or XWikiPreferences
and instead make code documents that will automatically create those
documents with defaulted settings (like they are now in the shipped
documents) from code if they do not already exist. It would also be neat to
have settings like "hide full email address" not in the code file but in a
central place so it will not be overwritten accidentally. In general, I
think it would help to have configurable "hard settings" in extra properties
and on upgrade check if the value was manually set. If they are set they are
ignored and not overwritten, if they are not set just use the default
defined in the code. One example for that, the recently modified panel shows
only 5 entries, I preferred to show 10, so it would be neat to just have a
property in the document that is empty on shipment. When a user views the
panel the code checks the property and if it is empty it uses the default 5
otherwise it uses the value provided in the property (e.g. 10).

Regarding the paper cuts, I report some of those I found on JIRA and/or the
IRC channel but since I am no longer anywhere near a productive environment
and I know my way around the system it is getting harder for me to spot them
as such... it is just like what I described, I don't think like the default
user anymore. Anyway, one of the bigger one that pop into my head just now
is that I remember a colleague having trouble using the Office Import in the
WYSIWYG editor for large documents could result in errors. Sometimes I could
not delete pages until I restarted Tomcat. The WYSIWYG editor does not alway
give the result which I would consider more suitable at that point (e.g.
color background in a table does not color the cells background but the text
background. I know that is correct from HTML POV but for an office user, I
think, the cell would make more sense) or does not even allow certain style
manipulations (e.g. vertical alignment or merging of cells, JIRA on that
exists already).

Thanks for working through my lengthy mess, yet again,
Johannes :-D

View this message in context: http://xwiki.475771.n2.nabble.com/Back-to-the-future-of-XWiki-tp6084764p6153047.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.

More information about the devs mailing list