river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: River revamp
Date Fri, 11 Nov 2016 05:23:15 GMT
File a JIRA ticket on INFRA project should work.

Specify which SVN subtree to migrate into each repository.



On Fri, Nov 11, 2016 at 1:15 PM, Patricia Shanahan <pats@acm.org> wrote:

> What is the current process for getting a writable GIT repository within
> ASF?
>
>
> On 11/10/2016 8:25 PM, Peter wrote:
>
>> Thinking about how to proceed with code and repo...
>>
>> * I want to bring code in from an existing git repo and keep commit
>> history (I'm the only committer).  Branched off a recent version of River
>> trunk.
>> * We want to change to using a git repo for River.
>> * Start building maven style modules from the ground up, starting with
>> JERI at low level.
>> * Separate out the qa test suite (integration tests), which is an ant
>> build that only depends on jars from river build.
>> * Where should jtreg test suite ( unit and regression tests) go?  Maybe
>> with each relevant module?
>> * junit tests with appropriate module...
>>
>> Thoughts / suggestions?
>>
>> Regards,
>>
>> Peter.
>>
>> Sent from my Samsung device.
>>
>>   Include original message
>> ---- Original message ----
>> From: Peter <jini@zeus.net.au>
>> Sent: 06/11/2016 08:23:06 pm
>> To: dev@river.apache.org
>> Subject: Re: River revamp
>>
>> Yes same pattern, some details are different for security reasons,
>> additional support is required for lower level protocols as object
>> endpoints.
>>
>> Also, for example, devices were on a 6LowPAN network, different types of
>> devices would subscribe to different multicast groups, to minimise their
>> responses, since some devices may rely on battery power, we don't want
>> them to announce their presence or respond unnecessarily as that wastes
>> power.
>>
>> There are a number of new IoT protocols being developed, I think we'll
>> need to provide some support for some to start with.
>>
>> AMQP is another interesting protocol.
>>
>> On the discovery side, in order to make a connection, the multicast
>> response will need to contain the application layer name, transport
>> layer name, contact address and port, eg:  MQTT, TCP, IP address:port.
>> Typically the nework layer will define the method of multicast.
>>
>> Cheers,
>>
>> Peter.
>>
>> On 6/11/2016 1:05 PM, Niclas Hedhman wrote:
>>
>>>  Ok, so this is more or less classic "surrogate" setup with JINI, right,
>>>  with some additional SEC stuff, right?
>>>
>>>  And that is a cool way to achieve interoperability with smaller devices
>>>  without ability to run a JVM, especially the original dream where
>>> devices
>>>  don't know about each other ahead of time (except by some interface)
>>>
>>>  I also see value where "IoT Service" doesn't bother with "Service
>>>  Registrar" in the "Jini sense" and the "IoT Device" only participate in
>>>  "Discovery" and then get a secure/trusted channel, onto which a
>>>  light-weight protocol, such as MQTT or CoAP, can be funneled in either
>>>  direction.
>>>
>>>
>>>
>>>  On Sat, Nov 5, 2016 at 2:26 PM, Peter<jini@zeus.net.au>  wrote:
>>>
>>>  Hmm lets try Ascii, hope line wrapping doesn't wreck it.
>>>>
>>>>
>>>>               |<----------------------| Multicast request
>>>>  Multicast   |                       |
>>>>  response    |---------------------->| Connection&  auth
>>>>               |                       | to discovered address
>>>>  RPCSEC_GSS  |<----------------------|
>>>>  auth        |---------------------->| RPCSEC_GSS Auth
>>>>               |                       | success, request
>>>>               |                       | bytes containing
>>>>               |                       | service proxy
>>>>               |      Register service |
>>>>               |    proxy&  attributes |------------------->|
>>>> Registration
>>>>               |      Mange reg lease  |<-------------------|
>>>>               |                       |                    |
>>>>               |                       |             Match
>>>>  |<-----------------| Lookup
>>>>               |                       |
>>>>  |----------------->|
>>>>               |                       |                    |
>>>>     | Authenticate Iot Service
>>>>               |                       |                    |
>>>>     | with bootstrap proxy
>>>>               |                       |                    |
>>>>     | Grant permission to download
>>>>               |           Auth client |<----------------------------
>>>> ----------|
>>>>  and deserialize service proxy.
>>>>               |  Return service proxy |-----------------------------
>>>>  --------->|
>>>>               |                       |                    |
>>>>     | Prepare service proxy
>>>>               |<----------------------------
>>>> ----------------------------------|
>>>>  execute RPC function call
>>>>    Function   |----------------------------
>>>> ---------------------------------->|
>>>>  with constraints
>>>>               |                       |                    |
>>>>     |
>>>>          IoT Device             IoT Service         Service Registrar
>>>>  Client
>>>>
>>>>
>>>>
>>>>
>>>>  On 5/11/2016 3:48 PM, Peter wrote:
>>>>
>>>>  Ok, will come back to the ascii art, I'll first attempt to attach a
>>>>> png.
>>>>>
>>>>>  There's an existing Java RPC implementation LGPL, with a maven build
>>>>> tag
>>>>>  =>  oncrpc4j-2.6.0
>>>>>
>>>>>  https://github.com/dCache/oncrpc4j
>>>>>
>>>>>  The implementation above supports /RPCSEC_GSS/ for security, although
>>>>>  there's a client side bug at present, but fixing it will be a lot
>>>>> less work
>>>>>  than reimplimenting it.
>>>>>
>>>>>  Basically RPC is the C equivalent of Java RMI.
>>>>>
>>>>>  Cheers,
>>>>>
>>>>>  Peter.
>>>>>
>>>>>  On 5/11/2016 10:32 AM, Niclas Hedhman wrote:
>>>>>
>>>>>  Sorry, I get the feeling that too much detail thinking is still in
>>>>>> your
>>>>>>  head. Hard for me to follow your thought process. A simple picture
>>>>>> (ascii
>>>>>>  art would do) would go a long way...
>>>>>>
>>>>>>  Niclas
>>>>>>
>>>>>>  On Sat, Nov 5, 2016 at 8:04 AM, Peter<jini@zeus.net.au>  
wrote:
>>>>>>
>>>>>>  Thinking about C and power constrained devices, how about the
>>>>>> following:
>>>>>>
>>>>>>>  * Write an ONC RPC java compiler, to create java code (instead
of C)
>>>>>>>  client stubs.
>>>>>>>
>>>>>>>  * Provide support for TLS and constraints.
>>>>>>>
>>>>>>>  * Provide an IPv6 constrained device announcement (C) and discovery
>>>>>>>  (Java)
>>>>>>>  utilities.  Create a standard so other languages can be supported
by
>>>>>>>  others.
>>>>>>>
>>>>>>>  * Write a java utility and service that manages proxies, registers
>>>>>>>  discovered constrained devices with a lookup service and manages
>>>>>>> it's
>>>>>>>  lease.  This utility can generate attributes (from Configuration)
>>>>>>> and
>>>>>>>  provide a bootstrap proxy (service) to allow clients to
>>>>>>> authenticate and
>>>>>>>  obtain the smart proxy used to communicate directly with the
device.
>>>>>>>
>>>>>>>  * Provide an interface for clients to notify the utility service
>>>>>>> when a
>>>>>>>  device is down.
>>>>>>>
>>>>>>>  Regards,
>>>>>>>
>>>>>>>  Peter.
>>>>>>>
>>>>>>>  Sent from my Samsung device.
>>>>>>>
>>>>>>>      Include original message
>>>>>>>  ---- Original message ----
>>>>>>>  From: Zsolt Kúti<la.tinca@gmail.com>
>>>>>>>  Sent: 03/11/2016 05:37:45 pm
>>>>>>>  To: dev@river.apache.org
>>>>>>>  Subject: Re: River revamp
>>>>>>>
>>>>>>>  A small footprint implementation of Jini's lookup service written
>>>>>>> in C,
>>>>>>>  fully JCK compliant.
>>>>>>>  http://www.psinapticcom/link_files/PsiNapticTelematics.pdf
>>>>>>>
>>>>>>>
>>>>>>>  A few years ago being involved in developing a streelighting
>>>>>>> management
>>>>>>>  system I tried to access them to no avail.
>>>>>>>
>>>>>>>  On Thu, Nov 3, 2016 at 8:09 AM, Peter<jini@zeus.net.au>
  wrote:
>>>>>>>
>>>>>>>  I've been conaidering that.  It should be possible to implement
>>>>>>> service
>>>>>>>
>>>>>>>>  discovery in C, any serialized java bytes required for a
proxy
>>>>>>>> could be
>>>>>>>>  stored on the device.
>>>>>>>>
>>>>>>>>  So these devices are services, but not clients.
>>>>>>>>
>>>>>>>>  Will respond with more soon
>>>>>>>>
>>>>>>>>  Regards,
>>>>>>>>
>>>>>>>>  Peter.
>>>>>>>>
>>>>>>>>  Sent from my Samsung device.
>>>>>>>>
>>>>>>>>      Include original message
>>>>>>>>  ---- Original message ----
>>>>>>>>  From: Niclas Hedhman<niclas@hedhman.org>
>>>>>>>>  Sent: 03/11/2016 12:39:33 pm
>>>>>>>>  To: dev@river.apache.org
>>>>>>>>  Subject: Re: River revamp
>>>>>>>>
>>>>>>>>  "IoT" is a term that for this discussion is a bit too wide.
The
>>>>>>>>  "thermostat" runs with a kB-sized microcontroller and is
>>>>>>>>
>>>>>>>>  struggling to get
>>>>>>>
>>>>>>>  security features in at all, and the "home router" is typically
>>>>>>>> (still)
>>>>>>>>  running from a 4-8MByte flash, which is impossible to even
get a
>>>>>>>> Java
>>>>>>>>  ME
>>>>>>>>  onto, so there is a lot of challenges when using "IoT"
>>>>>>>>
>>>>>>>>  as a blanket term.
>>>>>>>
>>>>>>>  So, I think a couple of concrete, do-able, use-cases
>>>>>>>>  need to be highlighted
>>>>>>>>  as examples, maybe a kind of "blue print" paper on how to
>>>>>>>>  do it with River.
>>>>>>>>
>>>>>>>>  I totally agree that the "mothership" model is
>>>>>>>>  outrageous from a consumer's
>>>>>>>>  perspective, a nasty vendor lock-in, that all vendors are
>>>>>>>>
>>>>>>>>  pushing for and
>>>>>>>
>>>>>>>  all consumers/users need to fight the best we can.
>>>>>>>>
>>>>>>>>  A very active home automation project is called "OpenHAB",
a
>>>>>>>> flurry of
>>>>>>>>  activity, connecting just about everything from your thermostat
to
>>>>>>>> your
>>>>>>>>  dog's toys. I have not looked closely at it, don't even
know if it
>>>>>>>> is a
>>>>>>>>  Java project as such, but it is one of the most active projects
in
>>>>>>>> the
>>>>>>>>  field of Home IoT.
>>>>>>>>
>>>>>>>>  Cheers
>>>>>>>>  Niclas
>>>>>>>>
>>>>>>>>  On Wed, Nov 2, 2016 at 10:41 PM, Patricia Shanahan<pats@acm.org>
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>  I think for this to work it is necessary to find out
>>>>>>>>  where IoT people hang
>>>>>>>>
>>>>>>>>  out, and discuss it there Do they already have a plan for
a secure
>>>>>>>>>  framework?
>>>>>>>>>
>>>>>>>>>  As a potential IoT user I'm looking for two things:
>>>>>>>>>
>>>>>>>>>  1. Security.
>>>>>>>>>
>>>>>>>>>  2. Server independence.
>>>>>>>>>
>>>>>>>>>  I don't want my thermostat to stop working if a server
I don't
>>>>>>>>> control
>>>>>>>>>  goes down or is taken out of service for any reason.
>>>>>>>>>
>>>>>>>>>  I think River may be a good basis for those features.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  On 11/2/2016 7:22 AM, Bryan Thompson wrote:
>>>>>>>>>
>>>>>>>>>  I look at this as open source for secure IoT.  The
>>>>>>>>>  need for security in
>>>>>>>>>
>>>>>>>>  IoT
>>>>>>>>
>>>>>>>>>  has been aptly demonstrated by recent DDOS
>>>>>>>>>>
>>>>>>>>>>  attaches based on compromised
>>>>>>>>>  devices.
>>>>>>>>>
>>>>>>>>>>  I do feel that interop is critical to success here.
>>>>>>>>>>
>>>>>>>>>>  Do we have any lurkers from the IoT manufacturing
>>>>>>>>>>
>>>>>>>>>>  space here?  People or
>>>>>>>>>  companies willing to invest time and resources for
>>>>>>>>>  a secure IOT platform?
>>>>>>>>>  Bryan
>>>>>>>>>
>>>>>>>>>>  On Wednesday, November 2, 2016, Peter<jini@zeus.net.au>
  wrote:
>>>>>>>>>>
>>>>>>>>>>  Utilising most of the existing discovery code, we
could use ipv6
>>>>>>>>>>
>>>>>>>>>>  multicast, for an exported remote object (service).
>>>>>>>>>>>
>>>>>>>>>>>  Then create a new class called RemoteDiscovery
to discover a
>>>>>>>>>>> service
>>>>>>>>>>>  dynamically, based on a name
>>>>>>>>>>>
>>>>>>>>>>>  So you export a service and it becomes dynamically
discoverable.
>>>>>>>>>>>
>>>>>>>>>>>  It's not going to step on any Jini discovery
lookup
>>>>>>>>>>>
>>>>>>>>>>>  stuff and it's going
>>>>>>>>>>
>>>>>>>>>  to be easily deployed by new users.
>>>>>>>>>
>>>>>>>>>>  Then once users realise there's more on offer they
>>>>>>>>>>>
>>>>>>>>>>>  can take advantage as
>>>>>>>>>>
>>>>>>>>>  their understanding develops.
>>>>>>>>>
>>>>>>>>>>  Cheers,
>>>>>>>>>>>
>>>>>>>>>>>  Peter.
>>>>>>>>>>>
>>>>>>>>>>>  Sent from my Samsung device.
>>>>>>>>>>>
>>>>>>>>>>>      Include original message
>>>>>>>>>>>  ---- Original message ----
>>>>>>>>>>>  From: Niclas Hedhman<niclas@hedhman.org<javascript:;>>
>>>>>>>>>>>  Sent: 02/11/2016 05:31:26 pm
>>>>>>>>>>>  To: dev@river.apache.org<javascript:;>
>>>>>>>>>>>  Subject: Re: River revamp
>>>>>>>>>>>
>>>>>>>>>>>  To put a bit more meat on Peter's condensed
list...
>>>>>>>>>>>
>>>>>>>>>>>  I put forward a proposal to sever the ties between
>>>>>>>>>>>
>>>>>>>>>>>  River and Jini itself,
>>>>>>>>>>
>>>>>>>>>  and instead re-focus River to be a a secured network
transport,
>>>>>>>>> with
>>>>>>>>>
>>>>>>>>>>  optional discovery. Starting point is of course
the JERI
>>>>>>>>>>>  module and Peter's
>>>>>>>>>>>  work to secure this transport, but in the longer
>>>>>>>>>>>
>>>>>>>>>>>  term look at alternative
>>>>>>>>>>
>>>>>>>>>  transport formats and eventually bindings to other
>>>>>>>>>
>>>>>>>>>>  languages, which I think
>>>>>>>>>>>  will be the major hurdle for long term acceptance
(no one is
>>>>>>>>>>> Java-
>>>>>>>>>>>
>>>>>>>>>>>  only
>>>>>>>>>>
>>>>>>>>>  nowadays).
>>>>>>>>
>>>>>>>>>  Jini's services, Reggie and so on, carries a lot of
>>>>>>>>>>>
>>>>>>>>>>>  negative connotation
>>>>>>>>>>
>>>>>>>>>  among people who were around back then, and except
>>>>>>>>>
>>>>>>>>>>  for where it has been
>>>>>>>>>>
>>>>>>>>>  adopted, I doubt that there will be any new uptake,
>>>>>>>>>
>>>>>>>>>>  so instead of making
>>>>>>>>>>
>>>>>>>>>  Jini (and its specs) the focal point of River, make
it
>>>>>>>>>
>>>>>>>>>>  to "Examples of what
>>>>>>>>>>>  River can be used for".
>>>>>>>>>>>
>>>>>>>>>>>  Another example of what can be done with River
could
>>>>>>>>>>>
>>>>>>>>>>>  eventually include
>>>>>>>>>>
>>>>>>>>>  connectors for popular platforms, such as Zookeeper,
>>>>>>>>>
>>>>>>>>>>  which could open
>>>>>>>>>>
>>>>>>>>>  avenues for new blood coming to River
>>>>>>>>
>>>>>>>>>  Concrete things; Apache Karaf is also a very small
>>>>>>>>>>>  community, yet they have
>>>>>>>>>>>  managed to put together a very exciting website,
and I think
>>>>>>>>>>> River
>>>>>>>>>>>  community could "borrow" a lot of that work,
making itself more
>>>>>>>>>>>  appealing,
>>>>>>>>>>>  promoting the new focus. I don't think much
coding is
>>>>>>>>>>>
>>>>>>>>>>>  needed to get this
>>>>>>>>>>
>>>>>>>>>  going, but packaging might be "fixed" to make
>>>>>>>>>
>>>>>>>>>>  consumption of the core
>>>>>>>>>>
>>>>>>>>>  functionality as easy as possible, preferably easier
than that.
>>>>>>>>
>>>>>>>>>  Once that is up-and-running starting the "reach
>>>>>>>>>>>
>>>>>>>>>>>  out" to other projects,
>>>>>>>>>>
>>>>>>>>>  individuals and press releases.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>  I hope that this will inspire some to more action.
>>>>>>>>>>>
>>>>>>>>>>>  Niclas
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  On Wed, Nov 2, 2016 at 2:25 PM, Peter Firmstone<
>>>>>>>>>>>  peter.firmstone@zeus.net.au<javascript:;>
>>>>>>>>>>>
>>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>>  A discussion recently ignited on river private
>>>>>>>>>>>>
>>>>>>>>>>>  about revamping the project.
>>>>>>>>>>>
>>>>>>>>>>>  For the benefit of the wider developer community
can we restate
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>>  suggestions here, feel free to reword, correct,
reject or
>>>>>>>>>>>>
>>>>>>>>>>>>  suggest  It was
>>>>>>>>>>>>
>>>>>>>>>>>  along the lines of:
>>>>>>>>>>>
>>>>>>>>>>>>  * Website revamp
>>>>>>>>>>>>  * Remove Jini focus, with a historical section...
>>>>>>>>>>>>  * Focus on new security features.
>>>>>>>>>>>>  * Make getting started simple, with just
the bare
>>>>>>>>>>>>
>>>>>>>>>>>>  bones basics, Extensible
>>>>>>>>>>>>
>>>>>>>>>>>  remote invocation with secure serialization.
>>>>>>>>>>>
>>>>>>>>>>>>  * Services, Javaspaces etc, become examples
of what
>>>>>>>>>>>>
>>>>>>>>>>>>  can be done with
>>>>>>>>>>>
>>>>>>>>>>  River, not what River  is.
>>>>>>>>
>>>>>>>>>  Regards,
>>>>>>>>>>>>
>>>>>>>>>>>>  Peter.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  Sent from my Samsung device.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  --
>>>>>>>>>>>  Niclas Hedhman, Software Developer
>>>>>>>>>>>  http://zest.apache.org - New Energy for Java
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  --
>>>>>>>>  Niclas Hedhman, Software Developer
>>>>>>>>  http://zest.apache.org - New Energy for Java
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>
>>
>>
>>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message