[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [soa-iwg] ECF remote services
|
Hi Zsolt,
Zsolt Beothy-Elo wrote:
<stuff deleted>
If you want to have ECF and remote services included in the SOA
package then you have to be the owner of the roadmap not only for the
runtime but also for the tooling.
This is just, plain, wrong. To force a runtime project to be
'responsible' for both runtime and tooling components, when a) there are
other projects doing tooling in this area; b) I/we don't have any
control over those projects; c) we don't have the resources to do both
runtime and tooling; d) even if we did have the resources to do that it
would be systemically wrong to do so (because we would be reproducing
much of the work that other projects were doing...unnecessarily and
uncooperatively).
Let me say it again: just, plain, wrong.
You really have to start to show
your involvement with the SOA IWG.
How would you have this involvement be realized? As Donald said, I
already have been involved...just not able to attend the meetings (so
far). Further, my primary involvement is and will be through the
implementation of an/the *OSGi SOA standard* in *working software*...not
taking meeting notes.
In addition, the working group's meetings have (so far) been far too
closed. As an example, there is no wiki page indicating when/what
time/what number the meetings are to be held (as far as I know) and no
public notes of the meetings on the wiki. This (among other things),
reduces participation, makes it unclear what, if anything, is being
done, and keeps the whole thing effectively closed.
I like what you and the rest of the
ECF team is doing, but I and more important SOPERA do not have a stake
in it and I am afraid that is true for the rest of the IWG members.
So what if SOpera does not have a stake in it? This is an Industry
Working Group, no? This is for the community...not Sopera...no? Why
should the development community (that wants to be able to do OSGi-based
SOA in a standard/consistent way), give a flying **** whether SOpera (or
any other vendor) has a stake in it?
And what other working group members are you talking about? I don't see
this list as exactly humming with working group participation. Further,
as far as I can tell the working group has not done anything...except
perhaps expend a lot of effort suppressing our work.
So
if you want to have ECF included in the SOA package start working in
the IWG.
What would I do? Attend the meetings? (which aren't public, and I can't
even figure out how to join?).
Given a choice between expending scarce resources on figuring out how to
attend IWG meetings...and implementing open, community-based
standards...as someone who cares about what the community actually needs
I'm going to choose the latter every time.
To summarize, what you are essentially saying is that to have something
included in the SOA EPP that
1) We have to do our own tooling...as a runtime project and with at
least 5 other projects doing overlapping tooling (which, by the
way...all our stuff can take advantage of/use unmodified, because it's
an implementation of an industry *standard*)
2) We also have to expend additional effort on this IWG...doing an
undefined/unknown set of things for/with a closed group.
There is *no* project at EF that is doing (or is capable of doing) these
things completely by itself...in addition to doing actual development
and supporting a real user community (which we have and are doing).
These criteria for EPP inclusion are arbitrary, and obviously designed
to exclude whoever and whatever you wish (NIH). In other words, this is
completely bogus.
Scott
