river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Zaffery <zaff...@gmail.com>
Subject Re: Future of Jini/River
Date Wed, 12 Nov 2008 05:53:51 GMT
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


Mime
View raw message