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 <p...@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 <j...@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<j...@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<j...@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.ti...@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<j...@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<nic...@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<p...@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<j...@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<nic...@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.firmst...@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
