Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 SRS0=InRV+f=ZM=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.90 as permitted sender)
Message-ID: <48BDC52E.5070807@wonderly.org>
Date: Tue, 02 Sep 2008 17:58:54 -0500
From: Gregg Wonderly <gregg@wonderly.org>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other development
 issues and ideas.
References: <507622.31248.qm@web33806.mail.mud.yahoo.com>
In-Reply-To: <507622.31248.qm@web33806.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gregg Wonderly <gregg@wonderly.org>

Wade Chandler wrote:
> Thinking one knows better versus flexibility and giving the ability to
 > do something are two different things. This is generally the hard part
 > about working within a group to try to get something working better for
 > ones own needs or others. Better, as I'm intending, doesn't mean better
 > in the terms of a specific persons views necessarily, but better in the
 > sense that something allows a developer to perform their role for a
 > given domain or task in the way which makes best sense for a given and
 > specific situation and not be locked into a particular pattern.

The discussions in the interview detail why the choice was made.  Having a 
public get/set pair which set a "constant" value is equivalent to having a 
public member that you just assign and reference.  So they chose to not require 
the use of the public get/set method.  A subtle but important issue I already 
mentioned, is that they did not want to download code and have live objects in 
the JavaSpace.  That would be required for the get methods to be called.

Not having live objects is a big deal!  It really makes certain things possible 
that are otherwise not.  It also creates certain limitations.  If you need 
something with live objects, try out my http://griddle.dev.java.net project. 
It's not a production ready system.  It does support live objects and 
comparisons using method calls.

If you want everything that JavaSpaces provides, but more, than that's where I 
think we are at in this discussion.  That "more" requires something different 
than what exists today.  There are ramifications to the "system" when you make 
those changes, and some of those (code versioning of live objects) can create a 
problem if you don't do all the design for versioning (serialization issues and 
data evolution as well) from the start.

>Anyways, this is why it helps to discuss things. So, an entry can have any type of data, 
 >and that data may have any type of information wrapped however it is needed:
>http://www.jini.org/wiki/Jini_Entry_Specification
> 
>It seems that link states that those fields, which may be of any type and serializable,
 >are still used as part of the template along with their fields, so are the public
 >fields still the only things used in comparison? If so, then the argument is 
still
 >valid as it negates any benefit of ecapsulation and comparison as private 
fields of
 >public properties are still not usable.

There is only one level that applies here.  There are no live objects.  What is 
compared is the "Serialized" form of the public objects as view from the Entry 
object's public fields values.

>I just want to understand it correctly, but
 >that link, per my understanding, states: only the public fields of any entry or a
 >fields fields are used for the template, and this means information must still be
 >copied around between narrowed and specific business objects and transfer objects
 >even when it does not make sense to do so in many situations and designs. If my
 >understanding is incorrect, then the rest of this email is useless.

I'm confused by this slightly.  Making sense, because an API/system design 
requires it, is a given.  Making sense because it's not what you want to do, or 
what you have to do with another system/API is perhaps an opinion, or at most, a 
point of interest worth discussion such as we are having here right?

>Do JavaSpaces use Comparable or any other such comparison interfaces to make
 >it possible for one to add their own comparison logic in the backend? I don't
 >see this in the specifications. Are there any plans for such a template
 >comparison interface to be added, or some other type of template descriptor
 >on the books? Has the idea of beans as templates been passed around as being
 >added to the specification?

Again, live code does not exist in the existing JavaSpace, so nothing is 
"called" in any Entry object.  The serialized form is compared for equality, 
that's all the spec requires for the equality check.

>Look, my argument is about making the technology more flexible; not to argue
 >for the sake of arguing about what concept is better over all. I tend to not
 >buy into such arguments as I have seen many things used in very innovative
 >and good ways through the years. Look how Hibernate, Spring, and other
 >libraries have influenced other specifications, and those are some very
 >flexible libraries.

Each system/library has certain limitations and necessities in the use of them. 
  All we are trying to say is that JavaSpaces has no live code use.  So anything 
about "code" in objects, is not touchable.  Again, this is why I created my 
griddle project.  During the development of the JavaSpaces05 spec, there was 
this exact kind of discussion.  So, I created griddle to give people something 
to play with and see how it might be used.  Didn't get a lick of interest in 
such capabilities really, so I'm not sure how to weigh your assertive arguments 
for such things against what the community has historically done.

>I could easily make a simple annotation library which does what I'm 
 >advocating for people automatically by lazily creating a transfer object
 >for a POJO or JavaBean, and that could live outside the specification.
 >I just think it makes good sense to have that live inside the
 >specification where such an extra library and logic are not always
 >needed. I guess both things could live there though. An annotation
 >library and the abiltiy to do more; this would allow many different
 > uses and not lock folks into a single pattern by allowing pure
 >transfer objects to be created without one needing to handle this
 >logic manually, TO->BO and BO->TO, and also allow for those small
 >and specific BOs in a given system to be used as both when needed.

My view is that separating a TO from a BO because of a "transfer" systems 
requirements, is exactly the right thing to do.  Creating a layer of abstraction 
in the application software to keep an external system from impacting the 
applications architecture is a good practice is it not?

For an HTTP web server resident servlet, would you have HTTP Request and 
Response objects running around inside your application, or would they only be 
visible at a particular interface?

>One can argue that is good or bad, but the real argument on 
 >whether something is good or bad should come down to a specific
 >use at a specific time within a specific design and not at some
 >high level argument of how it is always a good or bad thing.

Yes, by and large, you can make this kind of assertion.  But practically, all 
kinds of architectural issues come into play with software because APIs are not 
arbitrary.  Many have specific requirements for order of operations data types 
and behaviors (like hashCode() and equals()).  I agree in principal with your 
argument about the issues, but I'm not sure why your argument is pulling away 
from the facts that exist so that we can focus on the issues that make it hard, 
or impossible to do that and still meet the same service level agreements that 
exist today with the existing JavaSpaces specification.

Live code in the JavaSpace would change everything.

Gregg Wonderly