On Dec 20, 2008, at 8:59 AM, Dan Creswell wrote:
Michael McGrady wrote:
See infra:
On Dec 20, 2008, at 3:13 AM, Dan Creswell wrote:
Well that comes across nice and patronising....
I have the utmost respect for the work done on JINI or I would not be
here. Obviously JINI was built by a talented bunch of people.
However,
obviously there is a problem with JINI. JINI has failed to achieve
its
promise. Also, the problem with JINI is not engineering.
Obviously the
Prove it's not the engineering. Explain to me with clear reasoning
why
it's not about implementation of setup or configuration etc as Niclas
has suggested. Seriously if we've screwed up at that level I want
to know.
people involved on the project are preeminent engineers. The
problem is
architecture. Bringing up this issue is not patronizing. If you
don't
like it, sorry. But the topic has to be broached.
See this is the problem - in your opinion it's architecture, in your
opinion this topic must be broached and you seemingly require that I
accept the point. You're entitled to your opinion, but you still
haven't backed it up with fact and you admit that you haven't done
your
research.
In my opinion the problem with JINI is with the "ilities". Those are
non-functional values. Unlike functional values, these typically are
not engineering, fact, pure logic, etc. oriented, but architectural in
nature, about the structure of the system.
I don't care if you personally accept this or not. I just want to be
able to express the view without getting more heat than light in
return. Architecture is not like engineering. It uses heuristics and
experience and intuition. I could as easily say "prove it is
engineering" but I don't think that is helpful.
All the problems that are voiced, or almost all of them, such as ease
of use, structural issues, et. are not engineering problems. I call
them architectural because that is their province.
I was referring to your tone being patronizing, not your raising of
the
issue. You've read the cathedral and the bazaar and so have I.
Suggesting that we all go off and read it in the style you did (and
presumably on the assumption we haven't already read it and haven't
take
it on board) comes across badly.
Those suggestions, Dan, come from you. i pointed out merely that the
document specifically discusses the problem as a problem with open
source projects and as architectural in nature. If you already know
that, good for you. I suppose most would not have remembered it
without some reason or a reminder.
You're acting very superior like you know it all, care to list your
credentials to prove the point?
I can state a point of view that relates to JINI and is different
than
you without being attacked like this, i hope. I have to say from an
You can state a point of view indeed but you must back it.
Further you are "attacking" me and others when you say the things
you do
without backing them up with fact.
Please stop putting yourself above all others and claiming to be the
victim. You are victimising me and a few others with your repeated
and
unsupported assertions.
Note that whilst I've argued a lot with Niclas I haven't called him
out
in the way I have you. What might be the difference?
I have backed my point of view by giving in detail the criteria for
the judgments I made. The difference with Niclas is that he is
talking about a particular use and you can understand that. You
don't, I think, understand even with Niclas that the difficulty with
that use being accommodated is how JINI is structured.
My present principal tasks involve (1) work as principal
investigator on
funded R&D for a product connecting the cross-domain, multi-level
security, networks for the GIG (Global Information Grid of the United
States DoD) and the NAS (FAA, SWIM, etc) as well as SESAR (European),
etc. on an Air Force SBIR (AF081-028) through the Air Force labs in
Rome, N.Y. and (2) work on INSCOM products.
Cool, what software have you written?
What do you think the above is, hardware? I can add that I have
recently built a framework that sits on top of a mobile object
platform making the mobility and class loader issues transparent to
the application developer and pushes out EIP (Enterprise integration
Patterns) networks based on XML imperatives, automating system
configuration and monitoring.
Mike
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[email protected]
