Gregg, everyone...
You're last comment cuts to the chase of what River needs to move
forward, with more acceptance and participation from the community.
/I think we have to focus on the user experience and wrap a lot of the
mechanics into simple wrappers that don't remove access to the
details, but just provide reasonable defaults./
While Jini/River is amazingly great, unless the experience of using it
is _/drastically improved /_it will never gain momentum and die in
incubation. The Rails & Grails community follow the code-by-convention
paradigm, and their acceptance has been very rapid. If all of us who
are interested in River want it to succeed, then it needs to be made
painless to start and use just as the Rails/Grails crowd as done. The
Servlet versus EJB is another example where simple wins the race.
Servlets are easy to code, EJBs are /perceived/ as not easy...which one
is more prevelant today?
I want to be able to use River, but I honestly can't take the chance on
incorporating in an Enterprise unless there is a community to support
it. So why not start with Gregg's ideas and roll them in. Focus on the
user experience make it great. Then River will have something to talk
about, and could be pushed on InfoQ, TSS, etc....
- Dave Zaffery
Gregg Wonderly wrote:
Sam Chance wrote:
Gregg,
Please forgive me for what I'm about to say. While all this is
surely an
engineering marvel - and perhaps necessary, it has no impact or wow
factor
to motivate 'outsiders' to download, install and use it.
Here's my thoughts around this Sam.
o New lookup service:
Removes the lost codebase problem as an issue because you can pass
around the service object in marshalled form. It provides a bases
for concepts of marshalled data transmission and use in your service
so that you can separate the "container for transport" from the data.
In doing that, you provide the opportunity for random marshalling
technologies to be used, such as SOAP and other packaging.
o Jini Desktop environment:
Provides the basis for just install and use services. In concert
with
getting Seven out the door, there is the opportunity to provide a
simple
service deployment and use mechanism that would encourage the
creation
of Jini services. Today, the out of the box experience is raw and
full
of details that are not "creating the service". I created the stuff
in my startnow.dev.java.net project as the mechanism that I use for
creating services now. I just do
public class MyService extends PersistentJiniService {
public static void main( String args[] ) {
new MyService( args, null );
}
public MyService( String args[] ) {
super( args );
...get other config params and do setup...
startService();
}
}
and I have a Jini service up and running. We need an experience like
this where all the config details and all the appropriate defaults
just
happen for the user. The Seven mechanisms are similar, but the
API is
richer for plugability and there is the whole deployment mechanism.
Password access:
We see occasional traffic on the list about "how do I keep joe from
using my service if it is visible on the internet?" To me, these
hover
around the basic issue of how easy it is to do password based
authentication using a web interface.
I'm all for having some web interface capabilities. For me though,
that would be a serviceUI exercise. We would define the appropriate
UIDescriptor that would provide all of the details for getting a
"servlet" interface to a service. Someone would then just write a
service discovery bit for throwing into apache and it would then
automatically discover and make available a web service UI to the
"world".
Proxied Authorization:
Using the Java security system is a royal pain because of the issues
with how Subject and threads of execution create context that is not
always active. So, if you instead use an instance of the service
interface as a proxy to the real service, and bury in that proxy,
all the authorization implementation, then an existing service can
have authorization pasted on top of it without the sprinkling of
java security permission checks which pretty much lock you into one
mode of authorization. I think this would be a big help to a lot of
issues revolving around overall security of network services.
I don't expect to influence the community to make a sharp rudder
change, but
one is sorely needed to bring River from real obscurity to something of
relevance.
I think we have to focus on the user experience and wrap a lot of the
mechanics into simple wrappers that don't remove access to the
details, but just provide reasonable defaults.
Gregg Wonderly
--
All that is necessary for the forces of evil to take root in the world is for
enough good men to do nothing. -Edmund Burke
