This is one the driving factors behind Glyph - I can build a Jini
service, with an attached (albeit simple) UI and have it deployed in
less than ten minutes.
There is that unwritten "work in 10 minutes or I'm bored" rule with
tech. Jini as a technology is deservedly complex given the problems it
is trying to alleviate, or force the developers to face, and Jini the
'framework' (not a great fan of that word tbh) simply does not exist.
It's like building a pier out to sea and having great structural
supports but putting no decking on top so you can actually walk on it
Calum
2008/11/12 David Zaffery <[EMAIL PROTECTED]>:
> 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
>
>
