On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
> Thank you for this point of view from the industrial world! > > Before reading your answer I invested some time in browsing the > presentation done by Vincent and Tugduall Grall from eXo Platform (as > Guillaume pointed out in this same thread). First of all, I must > recognize that I didn't consider eXo as an option. I remember that more > than a year ago I tried to take a look at eXo, but I finally decide to > postpone this option: I was not able to understand how XWiki and eXo > interact. My fault! > > Pascal, have you chosen Magnolia after comparing it with eXo? Or, have > you tried eXo? > I did the same as you: just had a look at Exo... but Exo seems to be a full enterprise platform... So as I wanted quickly just a skinning system to integrate with XWiki, I chose among the solutions I knew and CMS were good candidates. Then I chose a Java platform and finally I chose Magnolia after some tries. I'm not really happy about Magnolia as the documentation is really poor and the version I used was quite buggy but it allowed me to do what I needed. I should have a look at exo to see how it has evolved since. > Pascal Voitot wrote: > > On Fri, Jul 24, 2009 at 9:09 AM, [Ricardo Rodriguez] Your EPEC Network > ICT > > Team <[email protected]> wrote: > > > > I don't have a precise answer and I don't want to say stupid things > because > > I'm not exactly an expert at workflow design even if I use that often > :)... > > My feeling is that these technologies are born from the industrial server > > movement... you know, a bit like J2EE servers... in a charicatural > sentence, > > I would say:"the bigger the better"... you take all the problems as a > whole > > and you provide a global solution for all problems... and then some > people > > say:"don't you think we could have something a bit more lightweight which > > fulfills only what we need while keeping the possibility to use the big > > server when we need it?"... and people find new ideas, concepts and > designs > > to make things more lightweight and you get things like Spring for > example > > (which is no more so lightweight anyway) and it makes change J2EE servers > > because these ideas are not so stupid... > > So now you take the great subject of automaton with states, workflows, > > orchestrations, business process management and you create a tool > allowing > > to model any process corresponding to the theory, you participate to some > > standardization meetings to make things a bit more abstract. Finally, you > > get something powerful, huge, complex that can do everything you need but > > also you don't need. > > In fact, if you look carefully, these questions about process management > are > > almost everywhere in the industry but there are no good solutions. There > are > > some professional tools but they cost so much that you can't even imagine > > paying that just to design a small publishing workflow... > > BPM, BPM, BPM, BPM everywhere :)... I say that because it seems Business > > Process Management is becoming a kind of holy grail for marketting people > in > > the software industry... but not sure technical people agree ;););) > > Ok, that's all for now... > > > > Let's think about one of this huge initiatives facing a even bigger > problem. A number of vast firms establish a partnership, identify and > define the huge problem, devote a huge amount of resources and get their > solution. They must use this solution! Some people, being outside of the > partnership (auto-excluded or not being able to join it for one or other > reason) start thinking in this not so stupid way you talked about. > They/he/she act as the core of a new initiative to which, little by > little, new developers and users become involved with the initiative. > They become a team, trust each others, feel comfortable working together > and solve their day-by-day issues using a new via (Ok, ok, this could > sound a bit like Alicia's World, but if harmony, ethics and moral issues > are not applied here, I won't be able to explain what this happens! > Business are at the core, but they are not enough) > For me, for us, XWiki is one of this "not so stupid ideas" :-) And we > feel confortable working here. The answers that we are trying to answer > now are devoted to decide why we must keep trying to solve our "business > issues" with XWiki, team and software, at the core of our toolscape. > I really agree with you. In my case, I can tell you that I chose XWiki after trying many other solutions and it appears to be the best solution for my problems in the open source world... I use XWiki not just for fun or because it's opensource but because it really fits my needs! > > Of course we do realize that XWiki needs more resources to go further > and, mainly, developers could spend some less hours tied to their > computers! :-) Let's keep trying to do something useful. > > In the last week, a number of Open Source initiatives has jumped in our > scenario as options to solve not-well-developed-yet XWiki issues (eXo, > Magnolia, Bonita, iText, jBPM,...) > I'm not sure all of these are really useful for XWiki :) > Sergiu proposed a really simple way of solving the problem of > "publishing authorization". We need something a bit more complicated, > perhaps just facilitate that the responsible/responsibles of a document > receive a warning when the people involved with the creation of a > document agreed on its contents and that the publication of that > document will be effective when responsibles, let's say, check an > agreement box. I think this problem is far from needing any kind of > fancy workflow framework and can be solved within XWiki without much > work. We will keep an eye on any further development on integration with > other projects and try to finally update to 2.x and start contributing > to development. > > > There are workflow engines in the opensource world but I don't know them > > precisely so I can't say they are simpler or better... > > This is my point of view from the industrial world :) > > Thanks for your thoughts and your work! > > Greetings, > > Ricardo > > -- > Ricardo RodrÃguez > Your EPEC Network ICT Team > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
