Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.

[Wade Chandler <hw...@yahoo.com>]

All,

If one were formulating an argument for the use of Jini and JavaSpaces versus JEE, what exactly would the decision maker be? I know you can use JEE inside Jini services, and thus they are complimenting each other in this regard, and then Jini services can be discoverable, but is that the real beauty of Jini versus EE? I guess I'm having a hard time reconciling why I should want to really dig into Jini more versus just continuing to use EE. 

I can have remote code with EE, and I can have it clustered and running on multiple backends. Such a thing would only be done in Jini, per my understanding, by having a Jini front end where the code which the service executes still executes in an EE environment using stateless or stateful beans. Too, JavaSpaces seem cool from the sense of remote memory, but I'm having a hard time reconciling why JavaSpaces are any better than EJBs except for the fact that I don't really have server storage coding for the backing JavaSpaces tuples, though for any type of application to survive shutdowns and crashes data would need to be stored in some type of a permanent data store such as a database. Using a database would make sense anyways, so it seems tuples/entries are better suited to temporary distributed memory, but again, maybe wrong here and needing clarity.

I know this is a Jini dev list, but I'm trying to reconcile these things to make sure I want to commit resources here as I am really interested in the automatic discovery of services and pluggability, and I'm very interested in distributed services, where service calls are distributed and clustered the server/service side so that multiple instances of a service handle different requests in the backend for a given front end, if this is possible with Jini services as part of the Jini specification. This would basically be clustered services.

Something bothering me about JavaSpaces entries is they force public fields/variables. To me they should operate off the same assumptions JavaBeans and serialization operate. EJBs work this way as well. Truly those things should be compatible thus true encapsulation can take place. I haven't figured out why entries differ from the other specifications.

Too, do I have the wrong idea about the River incubator? I was thinking it was to be the new place for work on Jini and JavaSpaces to progress forward, but I don't see documentation on the specifications, nor other information on the web site directly related to that type environment for progress. What is the overall goal here? The first sentence in the web site states "a project furthering the development and advancement of Jini technology". Is that the goal, and if so what does that actually mean? I notice links on the site to Jini lists/forums on java.sun.com, but I guess my understanding is that Jini and all related technologies, maybe even JSRs, are to start and end here now. What is the real story?

Just a side note. I had the privilege of mentoring a NetBeans project to create easy to use functionality to get people started using JavaSpaces, tuples, and entries. It seems a good start to a larger Jini environment. This was part of some work the NB Dream Team did for the NetBeans Innovators Grant program. You can see the project from Magdalena Dukielska at:
http://code.google.com/p/javaspaces-netbeans/

Thanks for any and all information,

Wade

 ==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org

Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.

[Greg Trasuk <tr...@stratuscom.com>]

Hi Wade:

I know there have been several responses so far, but I wanted to go back
to your original question.  Discussion is interspersed below.  I'm not
sure if the formatting comes out well as an email, so I may redo my
comments as a blog entry later on.

Cheers,

Greg Trasuk.

On Fri, 2008-08-29 at 20:31, Wade Chandler wrote:
> All,
> 
> If one were formulating an argument for the use of Jini and JavaSpaces versus JEE, what exactly would the decision maker be? 

I don't think this is the correct comparison.

JEE's primary use case is connecting web applications to an application
backend consisting of business logic and persistence, with the potential
for load balancing over multiple instances of the web container and
application container.  As such, JEE includes elements of remote method
invocation, transaction coordination and object-relational mapping, but
assumes a fairly static configuration and fairly tight coupling of the
web, application, and database components.  "Distributed" components are
generally assumed to be in the same datacenter connected by highly
reliable networks.  Having said that, the vast majority of deployments
end up with the web, business logic, and persistence components running
in the same application server, often with the database on the same
physical node.  This type of configuration hardly justifies any
distribution logic at all; hence the rise of Spring and similar
lightweight component-integration frameworks.

Jini is an enabling technology for service oriented architecture.  As
such, it is more appropriate to compare Jini to the WS-*/WSDL/SOAP/UDDI
universe.  In that light, some Jini's differentiations are as follows:

- Jini makes the assumption that a client of a Jini service is resident
in a Java Virtual Machine.  As such, it dispenses with the need to
define an interface definition language (e.g. WSDL), type system (e.g.
XML formatted according to an XML Schema) and remote procedure call
mechanism (e.g. SOAP over http) that has to try to support multiple
implementation environments.  We can define service interfaces as plain
old Java interfaces (and usually have only partial success, hence
WS-I).  Also, we can mostly avoid  Oddly enough, I frequently find
organizations implementing SOA using the WS-* stack but planning to use
Java for the entire implementation.
	- Note that I said the _client_ is resident in a JVM.  The service
doesn't need to be in Java, as we'll see later.

- Jini is designed explicitly around the Eight Fallacies of Distributed
Computing put forward by Deutsch
(http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing) and is
informed by the insights contained in "A Note on Distributed Computing"
by Kendall, Waldo, Wollrath, and Wyant
(http://research.sun.com/techrep/1994/abstract-29.html).  In particular,
it does a far better job of dealing with network unreliability (through
the leasing mechanism) and supporting security and distributed
administration than WS-*.  Also, because it doesn't impose the verbosity
of XML, it fares much better against the bandwidth and transport cost
fallacies.

- Given that clients of Jini services are in a Java environment, Jini
embraces the concepts of serialized objects and dynamically loaded
mobile code, and deals with most of the difficult aspects of that
embrace (identity issues, proxy verification, proxy trust issues, etc). 
Mobile code allows Jini to present some interesting possibilities:
	- Jini clients do not need to know anything about the communications
protocol used to communicate with the service.  (See Waldo, Jim, "The
End of Protocols",
http://java.sun.com/developer/technicalArticles/jini/protocols.html). 
Having said that, Jini/JERI provides a rich and secure Java Remote
Methods Invocation protocol, which we use more often than not.
	- What we normally think of as "remote objects" can actually be objects
that move between virtual machine, and have their code executed in the
virtual machine that is calling them.  This enables the concept of smart
proxies (see Dan Creswell's blog at
http://www.jroller.com/dancres/entry/stub_proxy_and_smart_proxy).  Many
people don't realize it, but the objects we pass as listeners to events
can also be smart proxies.  You might want to think about that one for a
while...
	- Since all that matters for a client to use a service is that we can
create an appropriate proxy for the service in Java, the services
themselves don't need to be implemented in Java or use any Java-based
communications protocol.  You could register a "Jini Service" that is
actually a proxy for a SOAP-based object or some other wire-level
protocol.  The Surrogate specification expands on this concept and
provides a simple way for connected devices to provide an appropriate
service.
	- It is trivial for a client to set itself up to receive asynchronous
callbacks or remote events from a service.  This is distinctly
non-trivial (tending towards impossible, but I don't like sweeping
generalizations) under the WS-* regime.  As such, Jini is much more
appropriate to GUI clients and event-driven system than WS-*.

- Multicast discovery completely removes the dependence on any physical
location information encoded in a service description (as in WSDL), and
any single point of failure issues (as with UDDI).  It is trivial, even
encouraged, to have multiple service registrars on the network. 
Services automatically register with multiple registrars, and clients
can easily find and query multiple registrars.

- Jini philosophy and technology (e.g. Leases and Transactions)
encourage us to deal with the complicated failure mechanisms present in
distributed systems.  As a result, Jini SOA's are far less fragile than
WS-*-based SOA's, and far easier to manage.  In particular, migrating a
service from one box to another is pretty much trivial, and doesn't
require any administration on the client side.  Not much code on the
client side either (as opposed to doing a UDDI lookup).

There are other differentiating factors as well, but those are the
biggies off the top of my head.

> I know you can use JEE inside Jini services, and thus they are complimenting each other in this regard, 
> and then Jini services can be discoverable, but is that the real beauty of Jini versus EE?
Are you suggesting that JEE makes Jini services discoverable?  It's the
other way around.

>  I guess I'm having a hard time reconciling why I should want to really dig into Jini more versus just continuing to use EE. 
Well, arguably, most "JEE" applications would be much better off using a
Spring container inside the web server, but we'll assume you actually
want the application to be physically distributed over multiple nodes. 
In that case, choice is really between a JEE-style cluster or a
service-oriented architecture.  If your goals require SOA, then you
should be using Jini.

> 
> I can have remote code with EE, and I can have it clustered and running on multiple backends. 
> Such a thing would only be done in Jini, per my understanding, by having a Jini front end where the code which the service 
> still executes in an EE environment using stateless or stateful beans.
No, you'd just have multiple service instances, perhaps with a smart
proxy that "load-balances" between the service instances.  Alternately,
JavaSpaces can be used to implement a nice "perfect" load-balancing
algorithm (the multiple-master-multiple-worker pattern).

>  Too, JavaSpaces seem cool from the sense of remote memory, but I'm having a hard time reconciling why JavaSpaces are any better
>  than EJBs except for the fact that I don't really have server storage coding for the backing JavaSpaces tuples, 
> though for any type of application to survive shutdowns and crashes data would need to be stored in some type of a permanent 
> data store such as a database. Using a database would make sense anyways, so it seems tuples/entries are better suited to 
> temporary distributed memory, but again, maybe wrong here and needing clarity.
One of the problems with a simple yet powerful concept like tuple-spaces
is that there are a lot of possibilities.  Different people see it
different ways, but I've always treated JavaSpaces as a loosely-coupled
communications mechanism.  I particularly like Ken Arnolds "Remote
Procedure Call to Nowhere in Particular" model (see
http://www.artima.com/intv/swayP.html).

> 
> I know this is a Jini dev list, but I'm trying to reconcile these things to make sure I want to commit resources here as I am 
> really interested in the automatic discovery of services and pluggability, and I'm very interested in distributed services, 
> where service calls are distributed and clustered the server/service side so that multiple instances of a service handle different 
> requests in the backend for a given front end, if this is possible with Jini services as part of the Jini specification. This would 
> basically be clustered services.
I apologize; I'm having difficulty verbalizing the exact differences,
but distributed services and clustered services seem like different
concepts to me.  Could you perhaps expand on what aspects of
"clustering" are important in this discussion?  Fail-over is a natural
part of the Jini Way.  Load balancing is not intrinisic to the Jini Way,
but is easily implemented using smart proxies or JavaSpaces.

> 
> Something bothering me about JavaSpaces entries is they force public fields/variables. To me they should operate off the same 
> assumptions JavaBeans and serialization operate. EJBs work this way as well. Truly those things should be compatible thus true 
> encapsulation can take place. I haven't figured out why entries differ from the other specifications.
Ken Arnold also explains this design decision in the Artima article
(http://www.artima.com/intv/swayP.html).  Along with his points on the
contract of an Entry field, there is a huge practical advantage to this
decision: The Space implementation never has to load the class that
derives from Entry.  The entry and all its fields can be marshalled on
the "write()"-ing client and unmarshalled on the "take()"-ing client,
and the actual Space can do all its communications and template matching
using the MarshalledObject instances.  This method has huge performance,
reliability, and maintainability advantages over having the Space load
the Entry class.

Probably the simplest thing is just to say that tuples aren't meant to
be encapsulated.  But, remember that the public fields can contain
domain objects that will be marshalled and unmarshalled as appropriate,
and those domain objects can be as encapsulated as you like - you simply
set the fields that hold domain objects to null when you create the
entry that defines the "search template".  The public fields are there
to provide the matching.  It's similar to storing a business object as a
BLOB in a database table;  you would still want to extract the
appropriate fields to select on.  You don't really need to copy the data
from a business object to the entry, unless that data is part of the
matching criteria.

> 
> Too, do I have the wrong idea about the River incubator? I was thinking it was to be the new place for work on Jini and JavaSpaces to 
> progress forward, but I don't see documentation on the specifications, nor other information on the web site directly related to that 
> type environment for progress. What is the overall goal here? The first sentence in the web site states "a project furthering the
>  development and advancement of Jini technology". Is that the goal, and if so what does that actually mean? I notice links on the
>  site to Jini lists/forums on java.sun.com, but I guess my understanding is that Jini and all related technologies, maybe even 
> JSRs, are to start and end here now. What is the real story?
River is Jini.  While some of us would like to keep the technology
specifications conceptually separate from the implementation (i.e as
Servlet/JSP is to Tomcat), there is no separate entity that manages the
specifications.  Which is a shame IMO, because the original Jini
Community Process was very well thought-out.  Alas, when the call came
to put money on the table to support an ongoing Jini Community separate
from River, everyone seemed to have forgotten their wallets in their
other trousers.

> 
> Just a side note. I had the privilege of mentoring a NetBeans project to create easy to use functionality to get people started 
> using JavaSpaces, tuples, and entries. It seems a good start to a larger Jini environment. This was part of some work the NB Dream 
> Team did for the NetBeans Innovators Grant program. You can see the project from Magdalena Dukielska at:
> http://code.google.com/p/javaspaces-netbeans/
> 
> Thanks for any and all information,
> 
> Wade
> 
>  ==================
> Wade Chandler, CCE
> Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
> http://www.certified-computer-examiner.com
> http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> http://www.netbeans.org
-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com

Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.

[James Grahn <jg...@simulexinc.com>]

Patrick Wright wrote:
> The Javadocs are excellent and the
> specification is actually helpful for solving real problems :).

Let's not get carried away.

The javadocs aren't the worst I've seen, but there's a real problem in 
that the javadocs sometimes wax theoretic on what a method may or may 
not do.

Take this gem from JavaSpace05.take(), for instance:
"an implementation may chose to take fewer entries from the space than 
the maximum available or the maximum allowed by maxEntries."

Swell.

I know, you're thinking, that's just because it's the interface (even 
though very wishy-washy even for that level); the reference 
implementation holds the answers.

Nope, undocumented.

Well, then by the principle of least surprise, surely the "take" method 
will simply do maxEntries (or at least Integer.MAX_VALUE, the upper 
limit of the collection it returns).   Why, this is even how the code reads.

Nope, swing and a miss.   Thanks for playing.    You should have looked 
in the package documentation for com.sun.jini.outrigger.   There you 
would have learned that there's a server-imposed limit that governs what 
the client could possibly return.   And that limit defaults to 100 entries.

That said, I was able to find out what was going on through the mailing 
list when some of the original implementors replied to explain what was 
happening.   So there is at least that fall-back when the documentation 
lets you down.

James

Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.

[Patrick Wright <pd...@gmail.com>]

Hi Wade

On Sat, Aug 30, 2008 at 2:31 AM, Wade Chandler
<hw...@yahoo.com> wrote:
> All,
>
> If one were formulating an argument for the use of Jini and JavaSpaces versus JEE, what exactly would the decision maker be? I know you can use JEE inside Jini services, and thus they are complimenting each other in this regard, and then Jini services can be discoverable, but is that the real beauty of Jini versus EE? I guess I'm having a hard time reconciling why I should want to really dig into Jini more versus just continuing to use EE.

I'll give you our perspective, since we evaluated just this choice
about two years ago after deciding to move our platform more
aggressively towards a services-based approach.

First, we don't use JavaSpaces. We haven't found a use-case in our
situation that would appear to benefit from it, and we use JMS for
asynchronous messaging. We did some performance comparisons of JMS vs.
JS and for straight message-passing performance, JMS was a clear
winner. But that was also because we didn't have a need for posting
and finding entries, for example, so weren't comparing on that basis.
We're not adverse to it, but are waiting to see if we have a need for
it before introducing another technology into our already-complex
technology stack.

As far as Jini, we felt, after some prototyping, that it was a pretty
safe choice. We knew more or less where our service boundaries were
going to be (or were headed), and knew that in most of those cases
we'd be going across the network anyway; so we'd have to update the
clients to handle network issues regardless of what technology we
chose. Since Jini is interface-based, we felt, if we had to back away
from Jini, we'd have a number of other options to choose from to
implement the interfaces and contact remote servers. Being
interface-based also meant rollouts were easier--we could deploy two
versions of the interface and back off to the stable one if
necessary--and testing became simpler as well.

Our experience has been positive thus far. A big upside is that we've
been able to implement not only dynamic discovery but also nice
failover and load-balancing solutions. We also find that with Jini,
we're pretty comfortable creating and hosting services of any size--we
no longer think of our platform as being based around large,
monolithic servers. We have services which are very very small and
very simple (such as propagating some possibly-dynamic configuration
to clients) and services that are made up of many interfaces and where
the service host's JVM has a fair amount of memory and needs a bigger
box to run on. I think Jini gives us flexibility in that regard (even
if it's only in how we imagine what's possible).

I'd add to that that in our experience, we've found no bugs in the
Jini SDK to date. Not that there aren't any waiting, but we've found
it to be very reliable and stable. The Javadocs are excellent and the
specification is actually helpful for solving real problems :).

Downsides--and I think here there's a clear distinction with JEE--most
of the documentation available online is old and in many cases
outdated (there's still quite a bit of Jini pre-2.0 around). There
haven't been any new books written in a while. None of us had any
experience with Jini prior to our switchover, and across the board
developers who we talk to from other companies haven't worked with it
either. The learning curve was fairly steep anyway, and lack of good,
up-to-date materials made it tough going at some points.

That said, the mailing lists are, surprisingly, amazingly good. Not
just for new questions but the archives as well. Many times I've been
able to track down answers just by searching old mail threads. The
community, when issues do come up, is incredibly knowledgeable,
friendly, and experienced.

Another issue is that we've had to write a certain amount of
infrastructure on top of what comes with the JSDK, for example, client
side discovery/selection libraries. My feeling is that the JSDK is
fairly low-level. There are projects out there that take you higher up
the stack, and in the future we may look at something like Rio to
build on.

I'll wrap up by putting in a good word for Jini service hosting: we
use Bantam (http://bantam.dev.java.net) to host a number of our
services, and it's saved a lot of time. With Bantam, we can wrap up
our services into WAR bundles and load them in a standard web
container, e.g. Tomcat. We can configure the services (and ultimately,
all the Jini configuration properties) using Spring, which is also a
big plus since we use Spring anyway. We now have project templates
available and can get new services started with almost no effort at
all. Tom, Bantam's project owner, deserves big kudos for his work (and
his patience in answering my thousands of questions!).

Good luck with your decision.

Cheers,
Patrick

Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.

[Sean Landis <se...@gmail.com>]

I just had one thing to add and so I've deleted the rest. I agree with
all of Gregg's comments...as usual :-).

...deleted...

>> Something bothering me about JavaSpaces entries is they force public
>> fields/variables. To me they should operate off the same assumptions
>> JavaBeans and serialization operate. EJBs work this way as well. Truly
>> those things should be compatible thus true encapsulation can
>> take place. I haven't figured out why entries differ from the other
>> specifications.

Gregg gave a fine explanation of why this is so. I would turn that
around and ask, "Why do you care if a transfer object is transparent?"

At first blush, it might seem like a nice idea to use business objects
as entries in a JavaSpace but I would argue that is a bad idea. Just
as it is a bad idea to pass BOs across web service boundaries, or
other distribution technology boundaries.

If you do so, you quickly increase fragility in the system because
end-points must agree on the model and this is burdensome from many
perspectives. I'll give one example but there are many others. Our
Product Object, in it's complete form (from a DB field perspective)
has over 150 fields. This is too big to pass across the wire.
Furthermore, most uses of this object only care about a small subset
of this object. Further furthermore, we don't want certain of that
information to leak out to clients.

We use transfer objects to resolve this problem. Transfer objects are
in the class of objects that exist merely for their state and contain
no interesting behavior. Here, encapsulation losses its value and
merely is unnecessary overhead.

So I don't think the transparency of JavaSpace entries is a problem
from an OO design perspective.

Sean

Re: Jini, JavaSpaces, JEE, some questions, and some other development issues and ideas.

[Gregg Wonderly <gr...@wonderly.org>]

Thanks for the questions Wade, others will have better responses I'm sure, but 
here's my take, in line.

Wade Chandler wrote:
> If one were formulating an argument for the use of Jini and JavaSpaces versus JEE,
> what exactly would the decision maker be? I know you can use JEE inside Jini 
 > services, and thus they are complimenting each other in this regard, and then 
Jini
> services can be discoverable, but is that the real beauty of Jini versus EE?
> I guess I'm having a hard time reconciling why I should want to really dig into 
> Jini more versus just continuing to use EE. 

Jini is all about exploiting mobile code everywhere.  It provides a model and 
services that really want that to be possible, and used widely.  For me, these 
services, the specs and their availability in the network are what makes Jini 
work well.  If you do JEE, it provides a mechanism for interfacing software with 
the network.  It, itself, doesn't provide standards at the level of network 
services that Jini provides from my perspective.

> I can have remote code with EE, and I can have it clustered and running on 
 > multiple backends. Such a thing would only be done in Jini, per my
> understanding, by having a Jini front end where the code which the service 
> executes still executes in an EE environment using stateless or stateful
> beans. Too, JavaSpaces seem cool from the sense of remote memory, but 
> I'm having a hard time reconciling why JavaSpaces are any better than
> EJBs except for the fact that I don't really have server storage coding 
> for the backing JavaSpaces tuples, though for any type of application to 
> survive shutdowns and crashes data would need to be stored in some type 
> of a permanent data store such as a database. Using a database would 
> make sense anyways, so it seems tuples/entries are better suited to 
> temporary distributed memory, but again, maybe wrong here and needing
> clarity.

Javaspaces is for conveying requests between interested parties, not for storing 
data.  You would, store data somewhere more resilient, and then formulate 
requests with references to this data that would fly around between parties, 
using the Javaspace for communications so that you can plug in new players 
without others having to know they exist.

For example, if you want to insert a step into a process, you might have the 
producer of the data comming into the new step, produce a different type data, 
have the new step, consume it, and then output something that was ready for the 
original receiver to use.  By using a Javaspace, the insertion only affects the 
producer, not the consumer in this example.  It might, of course be necessary 
for the original consumer to know something new about the changes made by the 
new step.  But, it might also be a convenient versioning mechanism as well.

> I know this is a Jini dev list, but I'm trying to reconcile these things
> to make sure I want to commit resources here as I am really interested
> in the automatic discovery of services and pluggability, and I'm very 
> interested in distributed services, where service calls are distributed
> and clustered the server/service side so that multiple instances of a
> service handle different requests in the backend for a given front end,
> if this is possible with Jini services as part of the Jini 
 > specification. This would basically be clustered services.

This plugability based on "type" of message consumed is a key feature of using 
the Java type system.  It is possible in other messaging mechanisms using, say 
XML, or other programming language neutral systems.  But, you can't send "new" 
behavior without having downloaded code.  Instead, you have to make every system 
aware of any semantic meaning the data carries, which you'd rather keep abstracted.

> Something bothering me about JavaSpaces entries is they force public 
> fields/variables. To me they should operate off the same assumptions
> JavaBeans and serialization operate. EJBs work this way as well. 
> Truly those things should be compatible thus true encapsulation can
> take place. I haven't figured out why entries differ from the other
> specifications.

One of the primary issues with JavaSpaces is to that it tries really hard to not 
download code.  In doing that, the marshalling between the writer and the space, 
extracts data from the class to send down to the space.  That data needs to be 
visible for the matching mechanisms used for read/take.  In order to keep from 
downloading code, it can't really "serialize" the data in the normal way.

This works well in many cases.  I created a exploratory project at 
jspace.dev.java.net, which does two things different.  One, it separates these 
key values, used for matching, from the data.  It provides for the use of 
marshalled or unmarshalled data for keys in this regard, by also including a 
matching implementation, which might marshall/unmarshall, or package key data in 
a particular way, that is advantageous for the application.

The space part also includes an executor mechanism along with an iterator 
similar to what Javaspaces05 added.  The executor allows you to send executable 
code into the space and run it there to do things when entries match.

The design allows for downloaded code to be used if an application needs it, 
with full serialization of all data.  But, it also allows you to customize its 
use so that you get behavior very much like a Javaspace without conventional 
serialization.

> Too, do I have the wrong idea about the River incubator?

The Sun team, and other committers have the lowdown on their intents here.

Gregg Wonderly