I'm going to throw this into the mix
2008/11/13 David Zaffery <[EMAIL PROTECTED]>:
> 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 <[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
>>>
>>>
>>>
>
> --
> 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
>
>
