27 Jul
2009
27 Jul
'09
12:06 a.m.
On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> 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:
For me, for us, XWiki is one of this "not so stupid ideas" :-) And we
On Fri, Jul 24, 2009 at 9:09 AM, [Ricardo
Rodriguez] Your EPEC Network
ICT
Team <webmaster(a)environmentalchange.net>
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)
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs