Hi Trevor, On Tue, Aug 11, 2009 at 4:14 PM, Trevor <[email protected]> wrote:

Hello. Please let me know if I'm using the wrong mailing list.

I am currently evaluating XWiki (along with several other wikis) for use within our small development team. We will be sharing the wiki with clients as well, so we have several criteria that MUST be met:

1. WYSIWYG editing

Brand new WYSIWYG editor.

2. Clean interface, small learning curve

We've got a great new skin / user interface on the way that's even better than the current one.

3. Fine-grained user access to pages

Check.

4. Security (the wiki will be on a server exposed to the internet, but will be private)

Check (I'll let someone else answer more extensively). 5. Good support base See below. In trying out XWiki Enterprise and looking through the documentation I think

it meets these requirements (definitely 1-3).

My questions are:

1. We will want to segregate the clients from each other (ie. they won't be aware of each other), but our development team would need one-login access to all content, across clients. ie. if a developer logs in, they would have access to all content; if client A logs in, they would only see client A's content, etc. Am I understanding correctly that with User Groups and proper ACL we could achieve this?

You could definitely do it. There might be one issue: if you use only one wiki, your clients will be able to view the user profiles of one another (unless you block access to the XWiki space, which has numerous side effects). A way to prevent this is to use XWiki Enterprise Manager, to open one wiki per client (clients having local accounts on those wikis) while your developers will be global users with access to all subwikis. That would fit neatly with your use case I believe. 2. I'm trying to get an idea of the support base behind XWiki: does the

support and development rely on a small number of developers (or only one), or on a true community of developers? I noticed the "XWiki Project Health" page is quite out of date (only going up to Nov/07).

Well, since the project is backed by a company (of which I'm part of) that finances most of the committers you're unlikely to see it disappearing from one day to the next :-) Right now we've got 10-12 active committers (active as in one commit per week average) and since all the code is under the LGPL license you don't risk having us going proprietary anytime soon either. Basically it's a win-win situation for our users ;-) We also spend quite a lot of time answering to questions on our users & devs mailing lists (as you can see). Additionally, should you ever choose to go for commercial support, you'll find a bunch of talented people most willing to help you (that's us, the folks at http://www.xwiki.com/ ) 3. We do not currently have Java server experience; will XWiki be easy to

install/run/manage securely without exposing ourselves and our clients to risks out of ignorance of the underlying technology? Is it inherently more secure than using PHP on an Apache webserver (as I have read), or does it just come down to security awareness?

I'm not a security expert, all I can tell you is that XWiki is running internally at companies such as EMC and EADS and their internal teams haven't shut it down yet, so using the proper configuration making XWiki secure should not be a problem :-)

Any comments or additional information would be welcome. Excuse me if I have asked questions that are readily available on the website -- I have looked through the online documentation but have also evaluated many wikis and my eyes are starting to blur.

Let your eyes blur no more - I think XWiki would be a great match for you (though I'm obviously deeply biased :-).

Thanks very much, Trevor

We're looking forward to your feedback :-) Guillaume

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

Hi Trevor, Trevor wrote:

If any users on the mailing list have trials or tribulations with these servlets and/or databases, any comments would be welcome.

Just some more candid comments :-) I think we could subscribe the whole five points list you have originally posted. I would exchange with each other points 1 and 5, being the support team/community the most important strength. From this team/community continuously sources great new ideas that are implemented in brand new features, changes in structure, plans for a new data model,... I thing that the devs list is a great example about how thinks evolve here. Perhaps the biggest weakness is the update process. Even it is not difficult, it is a bit tricky and, if you are not careful enough, it is possible to make common mistakes as overwriting modified pages with new versions included in a new default xar. Layout modification has been improved a lot. I am anxious to see the new skin that will be included with the brand new XWiki 2.0. We have at the moment a small XWiki installation running in a Suse Linux server and with MySQL as database backend. We are planning to install two more servers in the following few months to get at least a new "productions instance" and a reasonable development environment. We are a small group, so must be the weight of our opinion!, but XWiki has became centric to our collaborative infrastructure thus of our whole work. I am sure your experience will be greatly welcome in this win-win scenario! Cheers, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

Ricardo, thanks for your input. It's always valuable to hear from other users, no matter how small the group (our's is small as well). I hadn't put the original list of criteria in any particular order, but "support" probably was our first or second concern. Are you running with Jetty? I've seen reference in the mailing list about setting up a SecurityManager policy; do you use one? Guillaume, thanks for the information on the release versions. Hearing that the WYSIWYG improvements have been backported to the stable release carries much weight for us since it's so key. We will be proceeding with a full test of XEM and look forward to putting it into production if all goes well. Trevor

Trevor wrote:

Hi Guillaume,

Thanks for your detailed reply, I appreciate it.

On Tue, 11 Aug 2009 18:59:15 +0200 Guillaume Lerouge <[email protected]> wrote:

...

Brand new WYSIWYG editor. We've got a great new skin / user interface on the way that's even better than the current one.

Are you referring to v2.0 compared to v1.9?

One of our primary criteria is a well-rounded, solid WYSIWYG editor (for non-technical users), and I'm currently basing my judgement on v2.0 milestone 2. Is v2.0 running "well enough" to use on a lightly-used production server? Any timeline on when it will be released officially?

...

effects). A way to prevent this is to use XWiki Enterprise Manager, to open one wiki per client (clients having local accounts on those wikis) while your developers will be global users with access to all subwikis. That would fit neatly with your use case I believe.

Yes, I think that sounds like it would do what we need. Is XEM released for v2.0 yet? Or would we have to run 1.9?

Another question, regarding the choice of database: the download page says "Once you're more familiar with XWiki you might want to set it up on your own database or in your own container,..." Does this mean Jetty and/or HSQL are not robust enough for a production wiki instance? When it says "Standalone installation including a Jetty container and an HSQLDB database all set up." it seems to imply that this is *just* for first-time, inexperienced users, and maybe not for a live production system.

Jetty is good enough as a container for production use. Even Google recently switched from Tomcat to Jetty for its hosted apps. HSQLDB, on the other hand, is not suited for big wikis, since it keeps all the data in memory.

Ah, I see "Currently XEM only fully supports MySQL and Oracle RDBMS."

Thanks again for your candid answers.

If any users on the mailing list have trials or tribulations with these servlets and/or databases, any comments would be welcome.

-- Sergiu Dumitriu http://purl.org/net/sergiu/