I do not thing so. The point is to minimize the complexity for the people doing the import by breaking things up first so it can go into separate git repos immediately.
Bryan On Fri, Nov 11, 2016 at 10:38 AM, Patricia Shanahan <p...@acm.org> wrote: > I am a little troubled by the need to do the rearranging in svn before > copying to git. That seems to imply svn has better reorganization features. > > On 11/11/2016 3:22 AM, Peter wrote: > >> We've got a little work to do. >> >> Cheers, >> >> Peter. >> >> >>> [https://issues.apache.org/jira/browse/INFRA-12432?page=com. >>> atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>> ] >>> >>> Chris Lambertus updated INFRA-12432: >>> ------------------------------------ >>> Status: Waiting for user (was: Waiting for Infra) >>> >>> This will be complicated and time consuming as the svn repo doesn't >>> fit the usual trunk/branches/tags format. You may want to do some >>> consolidation or break this down into multiple git repos, for example, >>> river-site.git, river-rt-tools.git, etc. prior to us doing an SVN->Git >>> migration. If you'd rather have it all in one repo, let us know and >>> we'll see what we can do. >>> >>> >>> > Apache River migration from SVN to Git - Git commit access >>>> > ---------------------------------------------------------- >>>> > >>>> > Key: INFRA-12432 >>>> > >>>> URL:https://issues.apache.org/jira/browse/INFRA-12432 >>>> > Project: Infrastructure >>>> > Issue Type: New Git Repo >>>> > Components: Git >>>> > Reporter: Peter Firmstone >>>> > >>>> >>> >>> >>> -- >>> This message was sent by Atlassian JIRA >>> (v6.3.4#6332) >>> >>> >> >> >> On 11/11/2016 3:23 PM, Niclas Hedhman wrote: >> >>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>> >>>>> >>> >>
