river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Calum Shaw-Mackay" <calum.shawmac...@gmail.com>
Subject River and ease of use/development
Date Thu, 13 Nov 2008 09:31:29 GMT
I'm going to throw this into the mix

2008/11/13 David Zaffery <zaffman@gmail.com>:
> Hi Calum,
>
> I started playing around with using annotations to create Jini services,
> then I came across your project.  I am curious if there has been any
> discussion or acceptance of your annotations among the Jini/River community?
>    From my perspective, the Glyph annotations is a big step in the right
> direction of making River easier to use.  I really would like to contribute
> to making River into the power-house project that it could be.Any thoughts?
> Thanks,
> Dave
>
> Calum Shaw-Mackay wrote:
>>
>> 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 <zaffman@gmail.com>:
>>
>>>
>>> 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
>>>
>>>
>>>
>
> --
> 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