Re: [xwiki-devs] [BRAINSTORM] You're rewriting XWiki, you can use any technology in the world, describe it.

Hi Caleb, Great thread, good exercice. Like many of us I imagine I've been giving that question some thoughts already. I've written an article exactly one year ago about this topic [1] (not on rewritting XWiki per-se, but on writing a similar application/platform). My thoughts have partly evolved since then, although I still think most of what I've laid down there at the time. Basically I would go like this : - I would stick to the JVM, and to Java. - I would make it a RESTful web service. And probably even several if I were to be iso in terms of feature. An example of a feature that I would see live in a separated web service (so different process and different API host or subdomain) would be anything open office related. It does not belong to the base service, and would actually benefit being hosted on the same machine as an open office server. This is an example, I believe there are other features that do not belong in the base service (Scheduling ? Mailing ? etc.). It's SOA, though the base service (the base "wiki engine" let say) has to be self-sufficient and offer something that work standalone (even if it means no watch list, no office import, etc.) - Today I'm not so sure about JAX-RS as I was in my article. It's nice and and brings a lot "for free" but now I also think it has some limitations that can be penalties, such as limited dynamicity in the way you can play with routes. Though maybe this is mitigated by JAX-RS 2.0 filters. - Front-end templating would be done with dumb templating, for example handlebars.js or dust.js ; with a flexible intermediary layer for preparing the "context" needed for such templating mechanisms (written as groovy or JS scripts). - I would go for a RDBM (like Postgres) without an "industrial ORM". I think hibernate and friends bring too much complexity for too little value. They tend to impose themselves on the DB design instead of having DB design and object design exists independently and meet at the O/R layer. They make it hard for the developer to know what is executed against the DB (the "gut feeling" can be wrong) and when. Also lazy fetching does not solve any actual problem IMHO. - I would make anything query related (like searching for objects when building applications) happen against the search engine and not the DB. - I would use elasticsearch as a search engine. It can be very easily embedded (for development and simple deployments) or run as a separate cluster, it's schemaless and RESTful by nature. - I would embrace JavaScript fully on the "client" for changing state. It would be hard for me not to throw AngularJS in the mix. - In terms of UX, I would make the "administration" a different UI/UX than the wiki itself, and make it an actual "back office". - ... it's missing a lot of details, I'll come back if I have some time Actually I've been trying to put most of those ideas into action for some months, into a e-commerce/marketplace platform I'm building [2]. Now, I'm very eager to read what others think. Jerome [1] http://velociter.fr/journal/my-idea-of-a-modern-web-app-on-the-jvm [2] https://github.com/mayocat/mayocat-shop/ On 03/27/2013 02:12 AM, Caleb James DeLisle wrote: