Re: river.jar + spaces architecture

[MICHAEL MCGRADY <mm...@topiatechnology.com>]

I mean to create a sub-thread because of something of interest in The Heretic's (Patricia's) third aspect to JINI, which is very, I think, interesting, but do not want to change the topic because it is more important, perhaps.  Pay no attention to what is happening behind the curtain.

In 3 (below/infra), viz. "being prepared for failures of servers and networks", there is a whole lot of thought and discussion in the origins of JINI and JavaSpaces going back to the inventors of the tuple-spaces implementation of Linda, e.g. Gelertner and what's-his-name.  Prepared for "failures" means in one sense that information is not just a message but divorced from the senders and receivers and an entity in its own right in the IT domain, i.e., an entry with a (possibly) separate location.  This divorces the issue of the producer and consumer blowing up and the information blowing up.  The latter is important, the former is not or is not except in a different sense that is intimately related to being able to reconnect to the data (information).  That is, this is the sense I think in which JavaSpaces is more fundamental than JINI to JINI (River).  Producers and consumers in JINI are divorced from information and this means that the producers and consumers must be able to variously access the information but that the information have a space in which the information exists apart from the consumers and producers.

In a sense, then, as in the 8 fallacies of network computing, the "failures" or servers and networks is not at all a failure and is essentially expected behavior.  The difference is subtle but, I think, real.

MG




On Dec 31, 2010, at 11:27 AM, Patricia Shanahan wrote:

> 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, trasukg@trasuk.com 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
>> mmcgrady@topiatechnology.com
>> 
>> 
>> 
>> 
> 

Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
mmcgrady@topiatechnology.com