You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Gerard Fulton <cg...@gmail.com> on 2018/02/01 02:09:42 UTC
Prioritize Modernizing The Specification
Hi Guys,
I wanted to float an idea by list that has been in my head for several
years. The idea is to prioritize the modernization of the River
specification into a set of language a d transport agnostic architectural
principles. River currently supports architectural concepts like discovery,
events, proxies and more! In reality, both the implementation language and
communication transport are minor details. For example a discovery service
implementation could backed by DNS and exposed by a WebSockets
communications transport protocol. I my opinion the most important part of
the DNS discovery service example is the application protocol which
potentially could be defined by a request/response model.
As a Java developer, I fear that the wider adoption and growth of River are
being empeeded by our laser like focus on River's Java reference
implementation.
Feedback is a gift!
-Gerard Fulton
Re: Prioritize Modernizing The Specification
Posted by Peter <ji...@zeus.net.au>.
Yes, that's correct, there's still an IIOP exporter, although it doesn't
support secure sockets, so it's probably best used locally.
Interestingly, when I was looking at the OSGi remote spec, it needs
existing protocols in common at each endpoint. This is a little
different than Jini / River, where the protocol is part of the proxy, so
the client needn't know anything about that. I'm not looking at
comparing approaches, or determining which is better, obviously the OSGi
communication protocols could be used in a Jini / River proxy
implementation.
At this time at least, services can be program language agnostic, but
clients require the jvm, I guess it might be possible to do something on
Microsofts CLR or Android as well.
Regards,
Peter.
On 5/02/2018 8:38 AM, Gerard Fulton wrote:
> If I remember correctly the original releases of Federations and Jini both
> contained aspects of the IIOP protocol move code in an implementation
> language format. In today's world developers might use technologies IDL
> implementations like FlatBuffers and gRPC.
>
> https://google.github.io/flatbuffers/
>
> https://grpc.io/
>
> --Gerard
>
> On Sun, Feb 4, 2018 at 11:19 AM, Gerard Fulton<cg...@gmail.com> wrote:
>
>> I agree with the points made by Gregg about mobile code being one of
>> Jini's principal benefit and that there are multiple ways to implement the
>> mobile code concept. Hopefully we can refactor the Jini specifications to
>> contain narrowly scoped assumptions where the infrastructure, programming
>> model, and services as free as possible from implementation details.
>>
>> --Gerard
>>
>> On Sat, Feb 3, 2018 at 6:25 PM, Gregg Wonderly<gr...@wonderly.org> wrote:
>>
>>> The principal benefit of Jini is mobile code. Everything else is just
>>> network communications. The primary problem is inexperienced developers or
>>> web developers who just want to send a user interface around. ServiceUI
>>> makes that possible in Jini, but the lease services along with transaction
>>> services and all natures of mobile code allow you to create the complete
>>> UI/UX in one language with the ability to not write CSS, HTML and Java
>>> Script all glued together. Instead, you get an end to end, uniform
>>> development and runtime environment.
>>>
>>> The Web is full of mobile code in the form of JavaScript and other
>>> dynamically loaded and bound pieces. But it suffers from single threaded
>>> user interfaces and the limitations of the web, in general, around network
>>> restrictions.
>>>
>>> Gregg
>>>
>>> Sent from my iPhone
>>>
>>>> On Feb 1, 2018, at 5:39 AM, Peter<ji...@zeus.net.au> wrote:
>>>>
>>>> Hello Gerard,
>>>>
>>>> Help is always welcomed, the Jini standards are quite old, so yes, I
>>> think it's an area definitely in need of some love. Documentation or
>>> standards that explain the philosophies / design patterns River is based
>>> on, I can see how that adds appeal. I'll certiainly jump in and help with
>>> reviews, there might be others interested in becoming involved as well.
>>>> Thanks,
>>>>
>>>> Peter.
>>>>
>>>>> On 1/02/2018 12:09 PM, Gerard Fulton wrote:
>>>>> Hi Guys,
>>>>>
>>>>>
>>>>>
>>>>> I wanted to float an idea by list that has been in my head for several
>>>>> years. The idea is to prioritize the modernization of the River
>>>>> specification into a set of language a d transport agnostic
>>> architectural
>>>>> principles. River currently supports architectural concepts like
>>> discovery,
>>>>> events, proxies and more! In reality, both the implementation language
>>> and
>>>>> communication transport are minor details. For example a discovery
>>> service
>>>>> implementation could backed by DNS and exposed by a WebSockets
>>>>> communications transport protocol. I my opinion the most important
>>> part of
>>>>> the DNS discovery service example is the application protocol which
>>>>> potentially could be defined by a request/response model.
>>>>>
>>>>>
>>>>>
>>>>> As a Java developer, I fear that the wider adoption and growth of
>>> River are
>>>>> being empeeded by our laser like focus on River's Java reference
>>>>> implementation.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Feedback is a gift!
>>>>>
>>>>>
>>>>>
>>>>> -Gerard Fulton
>>>>>
Re: Prioritize Modernizing The Specification
Posted by Gerard Fulton <cg...@gmail.com>.
If I remember correctly the original releases of Federations and Jini both
contained aspects of the IIOP protocol move code in an implementation
language format. In today's world developers might use technologies IDL
implementations like FlatBuffers and gRPC.
https://google.github.io/flatbuffers/
https://grpc.io/
--Gerard
On Sun, Feb 4, 2018 at 11:19 AM, Gerard Fulton <cg...@gmail.com> wrote:
> I agree with the points made by Gregg about mobile code being one of
> Jini's principal benefit and that there are multiple ways to implement the
> mobile code concept. Hopefully we can refactor the Jini specifications to
> contain narrowly scoped assumptions where the infrastructure, programming
> model, and services as free as possible from implementation details.
>
> --Gerard
>
> On Sat, Feb 3, 2018 at 6:25 PM, Gregg Wonderly <gr...@wonderly.org> wrote:
>
>> The principal benefit of Jini is mobile code. Everything else is just
>> network communications. The primary problem is inexperienced developers or
>> web developers who just want to send a user interface around. ServiceUI
>> makes that possible in Jini, but the lease services along with transaction
>> services and all natures of mobile code allow you to create the complete
>> UI/UX in one language with the ability to not write CSS, HTML and Java
>> Script all glued together. Instead, you get an end to end, uniform
>> development and runtime environment.
>>
>> The Web is full of mobile code in the form of JavaScript and other
>> dynamically loaded and bound pieces. But it suffers from single threaded
>> user interfaces and the limitations of the web, in general, around network
>> restrictions.
>>
>> Gregg
>>
>> Sent from my iPhone
>>
>> > On Feb 1, 2018, at 5:39 AM, Peter <ji...@zeus.net.au> wrote:
>> >
>> > Hello Gerard,
>> >
>> > Help is always welcomed, the Jini standards are quite old, so yes, I
>> think it's an area definitely in need of some love. Documentation or
>> standards that explain the philosophies / design patterns River is based
>> on, I can see how that adds appeal. I'll certiainly jump in and help with
>> reviews, there might be others interested in becoming involved as well.
>> >
>> > Thanks,
>> >
>> > Peter.
>> >
>> >> On 1/02/2018 12:09 PM, Gerard Fulton wrote:
>> >> Hi Guys,
>> >>
>> >>
>> >>
>> >> I wanted to float an idea by list that has been in my head for several
>> >> years. The idea is to prioritize the modernization of the River
>> >> specification into a set of language a d transport agnostic
>> architectural
>> >> principles. River currently supports architectural concepts like
>> discovery,
>> >> events, proxies and more! In reality, both the implementation language
>> and
>> >> communication transport are minor details. For example a discovery
>> service
>> >> implementation could backed by DNS and exposed by a WebSockets
>> >> communications transport protocol. I my opinion the most important
>> part of
>> >> the DNS discovery service example is the application protocol which
>> >> potentially could be defined by a request/response model.
>> >>
>> >>
>> >>
>> >> As a Java developer, I fear that the wider adoption and growth of
>> River are
>> >> being empeeded by our laser like focus on River's Java reference
>> >> implementation.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Feedback is a gift!
>> >>
>> >>
>> >>
>> >> -Gerard Fulton
>> >>
>> >
>>
>
>
Re: Prioritize Modernizing The Specification
Posted by Gerard Fulton <cg...@gmail.com>.
I agree with the points made by Gregg about mobile code being one of Jini's
principal benefit and that there are multiple ways to implement the mobile
code concept. Hopefully we can refactor the Jini specifications to contain
narrowly scoped assumptions where the infrastructure, programming model,
and services as free as possible from implementation details.
--Gerard
On Sat, Feb 3, 2018 at 6:25 PM, Gregg Wonderly <gr...@wonderly.org> wrote:
> The principal benefit of Jini is mobile code. Everything else is just
> network communications. The primary problem is inexperienced developers or
> web developers who just want to send a user interface around. ServiceUI
> makes that possible in Jini, but the lease services along with transaction
> services and all natures of mobile code allow you to create the complete
> UI/UX in one language with the ability to not write CSS, HTML and Java
> Script all glued together. Instead, you get an end to end, uniform
> development and runtime environment.
>
> The Web is full of mobile code in the form of JavaScript and other
> dynamically loaded and bound pieces. But it suffers from single threaded
> user interfaces and the limitations of the web, in general, around network
> restrictions.
>
> Gregg
>
> Sent from my iPhone
>
> > On Feb 1, 2018, at 5:39 AM, Peter <ji...@zeus.net.au> wrote:
> >
> > Hello Gerard,
> >
> > Help is always welcomed, the Jini standards are quite old, so yes, I
> think it's an area definitely in need of some love. Documentation or
> standards that explain the philosophies / design patterns River is based
> on, I can see how that adds appeal. I'll certiainly jump in and help with
> reviews, there might be others interested in becoming involved as well.
> >
> > Thanks,
> >
> > Peter.
> >
> >> On 1/02/2018 12:09 PM, Gerard Fulton wrote:
> >> Hi Guys,
> >>
> >>
> >>
> >> I wanted to float an idea by list that has been in my head for several
> >> years. The idea is to prioritize the modernization of the River
> >> specification into a set of language a d transport agnostic
> architectural
> >> principles. River currently supports architectural concepts like
> discovery,
> >> events, proxies and more! In reality, both the implementation language
> and
> >> communication transport are minor details. For example a discovery
> service
> >> implementation could backed by DNS and exposed by a WebSockets
> >> communications transport protocol. I my opinion the most important part
> of
> >> the DNS discovery service example is the application protocol which
> >> potentially could be defined by a request/response model.
> >>
> >>
> >>
> >> As a Java developer, I fear that the wider adoption and growth of River
> are
> >> being empeeded by our laser like focus on River's Java reference
> >> implementation.
> >>
> >>
> >>
> >>
> >>
> >> Feedback is a gift!
> >>
> >>
> >>
> >> -Gerard Fulton
> >>
> >
>
Re: Prioritize Modernizing The Specification
Posted by Gregg Wonderly <gr...@wonderly.org>.
The principal benefit of Jini is mobile code. Everything else is just network communications. The primary problem is inexperienced developers or web developers who just want to send a user interface around. ServiceUI makes that possible in Jini, but the lease services along with transaction services and all natures of mobile code allow you to create the complete UI/UX in one language with the ability to not write CSS, HTML and Java Script all glued together. Instead, you get an end to end, uniform development and runtime environment.
The Web is full of mobile code in the form of JavaScript and other dynamically loaded and bound pieces. But it suffers from single threaded user interfaces and the limitations of the web, in general, around network restrictions.
Gregg
Sent from my iPhone
> On Feb 1, 2018, at 5:39 AM, Peter <ji...@zeus.net.au> wrote:
>
> Hello Gerard,
>
> Help is always welcomed, the Jini standards are quite old, so yes, I think it's an area definitely in need of some love. Documentation or standards that explain the philosophies / design patterns River is based on, I can see how that adds appeal. I'll certiainly jump in and help with reviews, there might be others interested in becoming involved as well.
>
> Thanks,
>
> Peter.
>
>> On 1/02/2018 12:09 PM, Gerard Fulton wrote:
>> Hi Guys,
>>
>>
>>
>> I wanted to float an idea by list that has been in my head for several
>> years. The idea is to prioritize the modernization of the River
>> specification into a set of language a d transport agnostic architectural
>> principles. River currently supports architectural concepts like discovery,
>> events, proxies and more! In reality, both the implementation language and
>> communication transport are minor details. For example a discovery service
>> implementation could backed by DNS and exposed by a WebSockets
>> communications transport protocol. I my opinion the most important part of
>> the DNS discovery service example is the application protocol which
>> potentially could be defined by a request/response model.
>>
>>
>>
>> As a Java developer, I fear that the wider adoption and growth of River are
>> being empeeded by our laser like focus on River's Java reference
>> implementation.
>>
>>
>>
>>
>>
>> Feedback is a gift!
>>
>>
>>
>> -Gerard Fulton
>>
>
Re: Prioritize Modernizing The Specification
Posted by Peter <ji...@zeus.net.au>.
Hello Gerard,
Help is always welcomed, the Jini standards are quite old, so yes, I
think it's an area definitely in need of some love. Documentation or
standards that explain the philosophies / design patterns River is based
on, I can see how that adds appeal. I'll certiainly jump in and help
with reviews, there might be others interested in becoming involved as well.
Thanks,
Peter.
On 1/02/2018 12:09 PM, Gerard Fulton wrote:
> Hi Guys,
>
>
>
> I wanted to float an idea by list that has been in my head for several
> years. The idea is to prioritize the modernization of the River
> specification into a set of language a d transport agnostic architectural
> principles. River currently supports architectural concepts like discovery,
> events, proxies and more! In reality, both the implementation language and
> communication transport are minor details. For example a discovery service
> implementation could backed by DNS and exposed by a WebSockets
> communications transport protocol. I my opinion the most important part of
> the DNS discovery service example is the application protocol which
> potentially could be defined by a request/response model.
>
>
>
> As a Java developer, I fear that the wider adoption and growth of River are
> being empeeded by our laser like focus on River's Java reference
> implementation.
>
>
>
>
>
> Feedback is a gift!
>
>
>
> -Gerard Fulton
>