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.
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?
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]
