On 12/31/2010 11:15 AM, MICHAEL MCGRADY wrote:
Just thinking below -->

I may misunderstand but are not you two in "violent agreement" in
principle?  Gr. Sim says that we should not force people to use a
piece of software in a too restrictive way and Greg says that we
should not freeze specific implementations by allowing them to infect
the APIs, which is the same value.

As an aside, do people think that JINI (River) is tied essentially to
the dynamic proxy loading concept to the extent that changing this
concept subverts the main thrust of JINI (River)?  This seems to be
true to me.

I'm not so sure - I've been thinking heretical thoughts about this. There seems to me to be three aspects to Jini, and I'm not sure we need them all in all installations:

1. Dynamic loading of proxies.

2. Encapsulation of a protocol inside a distributed module through use of a proxy.

3. Being prepared for failures of servers and networks.

Obviously, dynamic loading of proxies gives the greatest flexibility. On the other hand, many systems have layers of flexibility, and often offer a simpler, less flexible, starting point.

Does this make any sense?


And, if there is a conflict ("subversion") between the main thrust
and simplification of use, is there a way to serve two "masters"?
The value of simplicity of use should be "way high".  This also seems
true to me.

Einstein's famous quip that we should keep things simple but not too
simple comes to mind.  Perhaps keeping things simple for the users
might involve getting more complex in the architecture or layering of
the code and functionality?

or transitioning from thinking of "the users" to thinking of a range of users, with different needs. Someone who needs the full flexibility may be prepared to pay more in configuration complexity to get it.

Here's an example of the sort of thing I mean. I've needed to create a lot of similar charts in Excel, too many for doing it manually to be at all attractive. I solved the problem by writing some VBA code to automate it. Does that need mean everyone who uses Excel to add some columns of numbers should be expected to learn and use VBA? No, there are simpler, more obvious, less flexible ways of doing simple things.


How can the team "marry" what are the legitimate but seemingly
conflicting concerns of Gr. Sim and Greg?  This would seem to be the
ideal solution to the problem and involves finding a new question (I
believe in "question analysis" as the true QA), if the merger does
not introduce unacceptable complexity and brittleness into the
build.

MG


On Dec 31, 2010, at 9:11 AM, Sim IJskes - QCG wrote:

On 31-12-10 17:18, [email protected] wrote:
Isn't that already jsk-platform.jar?  I would object to anything
that subverts the dynamic proxy loading concept that is central
to Jini.

It is imperative that people don't, for instance, get the
service-registrar proxy impls in their local class path.  That
would break compatibility with future or alternate impls.

If it would be easier for people to work with river, why would we
be against it. It is about offering people options, not about
forcing people to use a certain concept. I do think to use the word
'subverting' is indicating a strong tendency to force people to use
a certain piece of software in the way you think they should. I
think this is way too directive.

Gr. Sim

Michael McGrady Chief Architect Topia Technology, Inc. Cel
1.253.720.3365 Work 1.253.572.9712 extension 2037
[email protected]





Reply via email to