Re: Fwd: [jira] [Updated] (INFRA-12432) Apache River migration from SVN to Git - Git commit access
On 13-09-16 13:57, Peter wrote: I don't have strong feelings about it, I have heard that git history isn't as good as svn, but merge is much better. I know we've had merge issues in the past with svn, but I haven't experienced history issues with git yet. dont overestimate the power of git rebase : https://git-scm.com/book/en/v2/Git-Branching-Rebasing#The-Perils-of-Rebasing G. Simon
Re: Fwd: [jira] [Updated] (INFRA-12432) Apache River migration from SVN to Git - Git commit access
Could you make a proposal how to arrange the git repo(s)? Please mitigate for: http://programmers.stackexchange.com/questions/206668/using-multiple-git-repositories-instead-of-a-single-one-containing-many-apps-fro http://programmers.stackexchange.com/questions/161293/choosing-between-single-or-multiple-projects-in-a-git-repository G. Simon On 09-09-16 13:14, Bryan Thompson wrote: > I have become significantly pro-git over the last few years. I feel that > it is much more nimble, and I think the goal here is to help make river > more modular and gain the ability for an improved pace of development. > > Can you expand on your objection about scripts and complexity incurred? > > Bryan > > On Fri, Sep 9, 2016 at 1:40 AM, Simon IJskes - QCG wrote: > >> If any, please dont. >> >> The amount of scripting or addons that is needed to have multiple repos >> integrated does not outweigh the perceived benefits of git. >> >> The amount of work in forking, pushing, merging etc. is a lot compared to >> subversion commits. >> >> You can have your own git, sync it with subversion, and back patch the >> changes into subversion. >> >> So you can still have your own git, and have subversion for the project. >> >> OK, subversion is not as nimble as git. But so fast we are not really >> going are we? >> >> G. Simon
Re: Fwd: [jira] [Updated] (INFRA-12432) Apache River migration from SVN to Git - Git commit access
If any, please dont. The amount of scripting or addons that is needed to have multiple repos integrated does not outweigh the perceived benefits of git. The amount of work in forking, pushing, merging etc. is a lot compared to subversion commits. You can have your own git, sync it with subversion, and back patch the changes into subversion. So you can still have your own git, and have subversion for the project. OK, subversion is not as nimble as git. But so fast we are not really going are we? G. Simon On 08-09-16 06:01, Peter wrote: Anyone have thougts on this? Sent from my Samsung device. Include original message Original message From: Chris Lambertus (JIRA) Sent: 08/09/2016 10:48:21 am To: j...@zeus.net.au Subject: [jira] [Updated] (INFRA-12432) Apache River migration from SVN to Git - Git commit access [ 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
Re: Draft report
+1 On 06-08-16 21:59, Patricia Shanahan wrote: Here is a draft of the August 2016 board report. As always, suggested changes are welcome. == ## Description: - Apache River software provides a standards-compliant JINI service. ## Issues: - There are no issues requiring board attention at this time. Although the troubles discussed last quarter persist, there is on-going discussion of possible future directions. ## Activity: - There has been little activity. ## Health report: - The technical and people problems discussed last quarter have not yet been solved, but neither have they killed the project. In the last two months there have been threads on dev@river.apache.org, involving a total of 6 people, discussing how to support languages other than Java and how to take River in an IoT direction. ## PMC changes: - Currently 13 PMC members. - No new PMC members added in the last 3 months - Last PMC addition was Bryan Thompson on Sun Aug 30 2015 ## Committer base changes: - Currently 15 committers. - Dan Creswell was added as a committer on Mon Jun 20 2016 ## Releases: - Last release was river-jtsk-2.2.3 on Sat Feb 20 2016
Re: Attic? Was: Re: Lotj - languages other than java
On 05-07-16 14:51, Bryan Thompson wrote: GitHub (at least) provides excellent tracking. It is a matter of how you define policy for PRs. We do not accept PRs unless the author is a contributor with appropriate CLAs for the project. So it works out very nicely for us. Every single commit and its authorship remains visible and that metadata can be easily accessed. Is changing the version control system really going to change the problems we have? The same goes for maven or not, gradle or ant, etc. One direction wants a stable release with bugfixes, and strict maintaining of the original api, the other side wants to change things. No resolution in sight. I really like the Apache governance, and it gives everybody the freedom to fork it under its own. Apache is definitly not the problem here. Apache is a tool, a tool that shows us that we need to cooperate in order to make progress. You can switch to git, and fork all you like, like so many other projects. But then you have a few forks, sitting stale on github. With sometimes an individual caring about it, or more times not. Apache goes beyond individuals, and currently it shows we haven't made that step. G. Simon -- QCG, Software development, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Lotj - languages other than java
On 04-07-16 10:37, Peter wrote: > I'd like to see the project return to the days where we had a number of > active committers working together on the same goals I'm sorry that i did not immediately answered your email. I think there needs to be more buy-in for change, than only the two of us. Also, the needs that i had for a easy communication system are covered by code developed in house. It allows for send and post, and async return of exceptions. A deviation from the river model. Maybe we can restart as a universal library for safe-RMI. With easy options for connections to and from known (or discovered by outside means) endpoints, IPv6, poking through UPNP and NAT firewalls, multi-homed host capable (without -D options on the command line). Modular addable lookup services, discovery, identity, locking, tspaces, etc. But at least a system with a very low knowledge threshold, and small jar footprint to get things working. We could use a more modern declarative system for specifying security needs, so that later we could create adapters for in and outbound rpc protocols with a bigger market reach. But then again, there are a lot of people reading this, and a big part of them having no interest at all in incompatible improvements, and i see no other option than leaving them behind, with a jini compatible maintenance release. This will certainly tear the river community apart, or at least cause a lot of friction. So when i see only the two of us, moving in a new direction, i can't help feeling, what is the use of it all. G. Simon
Re: Lotj - languages other than java
If you solve the 'barrier' of the service discovery, do you also want to provide universal access to the java services in the form of microservices? It is doable to take any 'more used' service discovery solution and use this as the river discovery. To introduce a level of abstraction with the same primitives as the current river discovery mechanism offers. River would then have adapted a more common discovery mechanism. Next thing that we should decide, is how far do we go into universality. I see univeral type systems, different serialisation plugins on the horizon. The biggest showstopper for me was the API compatibility. In order to make any progress we need a more agile process for modifing the API. If we leave compatibility behind us, we could ask our selfs, what benefit are we providing for the users? What can we introduce that does not duplicate what is already in the market. For a java developer, i think there is no need to convince, they can see benefits in just having a java API to program against. We need to think about the environment where java receives a lot of 'non-love', how we can create a 'whow, java isn't all that bad, look at that easy solution' experience. I think that river lost the spot it could have, as a java only solution to JSON, XMLRPC, SOAP, etc libraries for java. From a helicopter view, what does it do? Whe provide secure RPC, with discovery and scaling. And we make it hard to use. G. Simon On 30-06-16 05:37, Peter wrote: Currently with River, you need java to participate. Other languages can provide services, but you need a jvm to participate. Most of discovery is language agnostic, so any language can participate in discovery. The major limitation for other languages is the lookup service. Security issues and complexity also relate to the lookup service. My thoughts are that a lookup service that performs search and registration, but provides a language independent and secure means of contacting service providers would be beneficial. Anyone interested in discussing further? Regards, Peter. Sent from my Samsung device.
Re: Does it really make sense to have a "Convenience Binary" artifact?
On 21-01-16 09:51, Greg Trasuk wrote: In going through the exercise of cleaning up the release artifacts, I’ve started to wonder if it actually makes sense to publish a “binary distribution” of the JTSK separately from publishing the artifacts to Maven Central. Opinions? Please keep the binary distribution. I can't imagine that it is so hard to keep the few extra lines in the scripts. G. Simon -- QCG, Software development, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Release 3.0, package rename and ServiceProxyAccessor
On 06-01-16 18:49, Simon IJskes - QCG wrote: On 06-01-16 13:38, Peter wrote: Your security analysis is too narrow, your thinking like a user, not an attacker. An attacker is not going to send you a proxy to load into a standalone Classloader. She has the choice of the entire classpath, not you and not River, that's right it's the senders choice, not the receivers. She's looking for vulnerable classes on your classpath. ObjectInputStream will load the attackers instructions. There's no protection domain on the stack representing the attacker, the attacker is looking to deserialize into privileged context, the attacker wants AllPermission. This all occurs before your remote method call even returns. Once the the attacker has privileges, she can create her own URLClassLoader grant AllPermission to her downloaded code, install her own security manager. https://cwe.mitre.org/data/definitions/502.html https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=27492407 Has a number of secure coding recomendations. G. -- QCG, Software development, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Release 3.0, package rename and ServiceProxyAccessor
On 06-01-16 13:38, Peter wrote: Your security analysis is too narrow, your thinking like a user, not an attacker. An attacker is not going to send you a proxy to load into a standalone Classloader. She has the choice of the entire classpath, not you and not River, that's right it's the senders choice, not the receivers. She's looking for vulnerable classes on your classpath. ObjectInputStream will load the attackers instructions. There's no protection domain on the stack representing the attacker, the attacker is looking to deserialize into privileged context, the attacker wants AllPermission. This all occurs before your remote method call even returns. Once the the attacker has privileges, she can create her own URLClassLoader grant AllPermission to her downloaded code, install her own security manager. https://cwe.mitre.org/data/definitions/502.html -- QCG, Software development, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-445) Remove the Activation subsystem and JRMP support from the 2.2 branch
On 26-11-15 05:19, Greg Trasuk wrote: The changes in RIVER-445 remove the activation system and the JRMP exporter, and associated QA tests, which is a change to the public API. Our conventions require a vote on changes to the public API. Since we’ve discussed the intent of these changes previously (and had general agreement), I think it’s appropriate to call a vote on the patch immediately. The vote will remain open until at least UTC Dec 1 (that’s more than 72 hours, but our American friends have Thanksgiving and Black Friday to contend with). It’s a lazy-consensus vote, however according to Apache conventions on voting for code changes, any ‘-1’ votes constitute a veto.If there are no ‘-1’ votes by Monday evening, I’ll apply the patch to the 2.2 branch. +1: [ ] I am in favour of this proposal +0: [ ] I am not opposed to this proposal -1: [ ] I am opposed (please provide an explanation) +1 -- QCG, Software development, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Dependency on Sun internal API's
On 22-05-14 13:31, Bryan Thompson wrote: This is all good, but I would personally be interested in getting to a release based on the QA branch with less remaining development. I would suggest rapid iterations for releases with incremental change until a QA branch based release is stable. Yes, if possible we could sync up the trunk, by visual diffing trunk and qa_refactor, merging patches into trunk, commiting to trunk and release in small controlled steps. Netbeans is capable of doing that. Gr. Simon
Re: [VOTE] Patricia Shanahan for PMC Chair
On 19-05-14 13:19, Peter Firmstone wrote: Come on people, we need at least three votes to nominate a new Chair. Lets give this project one last shot. Tom & I have already voted in favour. Peter. +1
Re: Modularization
On 01-05-14 00:29, Peter wrote: - Original message - > On 30-04-14 02:02, Dennis Reedy wrote: > > > A this point I'm soliciting opinions and thoughts. Note that using > > Gradle is certainly an option here, the breakout into multi-modules is > > not tied to Maven, it's based on accepted conventions. I chose Maven > > because it was the quickest (for me) to get going. > > Good thing! Just to show support! I applaud a separation into multiple > source trees, as a starting point for modularization. > > Any change we can re-apply your effort on trunk while maintaining > subversion history? i.e. 'svn mv' commands? Lets wait until after confirming the modular build structure though. How do you define this milestone? On what step, decision, or positive outcome shall we wait? Gr. Simon
Re: Modularization
On 30-04-14 20:57, Simon IJskes - QCG wrote: On 30-04-14 02:02, Dennis Reedy wrote: Any change we can re-apply your effort on trunk while maintaining subversion history? i.e. 'svn mv' commands? if so, we can adjust the ant script to maintain compatibility (as an intermediate step). Gr. Simon
Re: Modularization
On 30-04-14 02:02, Dennis Reedy wrote: A this point I'm soliciting opinions and thoughts. Note that using Gradle is certainly an option here, the breakout into multi-modules is not tied to Maven, it's based on accepted conventions. I chose Maven because it was the quickest (for me) to get going. Good thing! Just to show support! I applaud a separation into multiple source trees, as a starting point for modularization. Any change we can re-apply your effort on trunk while maintaining subversion history? i.e. 'svn mv' commands? Gr. Simon
Re: Research / experimental branch
On 18-02-14 08:27, Peter Firmstone wrote: Well these things are well and good, and yes we have the skunk area where we can all do our individual things, but we can't develop in trunk either, due to sensitivity. We need somewhere we can colloborate on ideas, somewhere developers are free to work together, where no idea is rejected before it can be demonstrated, at the moment very few ideas are "good enough" and we're stuck with a very outdated codebase. We need to have something for the future, or there simply won't be one. I see this as a well intended attempt to solve something that is fundamentally wrong with river at the moment. Only you are trying to delay the moment where it goes wrong. We can create code, but we still havent repaired river as it is. We are trying to please a non existing consumer who doesn't like any change. This way we will only ever release maintenance revisions. And this sensitivity, this is really where the problem lies. We have users, we have delivered very few benefits to them, because of our sensitivity. So when we stop beeing so sensitive and start changing things nothing changes for the ones that do not like our changes. But we will start delivering benefits to others and ourselfs. For the old users nothing hase changed. Still no new benefits. We need to modernize river. Otherwise we will be (and are) working for the past. Gr. Simon
Re: Research / experimental branch
Simple, less decided than on removal of the JRMP. I've never used activation. I wouldnt use it. What you are proposing is a river lite. RPC + registry + discovery. I believe this is a good approach. JSON, i like the idea. Code mobility by external means. Also good. Another experimental branch, i wouldnt support. I'm all for development on trunk. Branches are for QA and patches. Gr. Simon On 17-02-14 15:01, Greg Trasuk wrote: Hi Simon: What are your thoughts on the Phoenix service and activation system? Cheers, Greg Trasuk On Feb 17, 2014, at 7:07 AM, Simon IJskes - QCG wrote: On 17-02-14 13:06, Simon IJskes - QCG wrote: On 15-02-14 19:45, Greg Trasuk wrote: I wonder if we can just discuss the idea of removing activation and JRMP support from trunk? For me, JRMP is a no-brainer - the functionality is much better covered by JERI. I think JRMP was only there for backwards compatibility to Jini 1.2 services. +1 Sorry. too quick. +1 on removing JRMP. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Research / experimental branch
On 17-02-14 13:06, Simon IJskes - QCG wrote: On 15-02-14 19:45, Greg Trasuk wrote: I wonder if we can just discuss the idea of removing activation and JRMP support from trunk? For me, JRMP is a no-brainer - the functionality is much better covered by JERI. I think JRMP was only there for backwards compatibility to Jini 1.2 services. +1 Sorry. too quick. +1 on removing JRMP. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Research / experimental branch
On 15-02-14 19:45, Greg Trasuk wrote: I wonder if we can just discuss the idea of removing activation and JRMP support from trunk? For me, JRMP is a no-brainer - the functionality is much better covered by JERI. I think JRMP was only there for backwards compatibility to Jini 1.2 services. +1 -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
On 12-02-14 17:00, Greg Trasuk wrote: OK, fair enough. I’ll close this issue and open another one that just makes sure the jars aren’t in the source distribution (that _is_ an Apache requirement) without adding Ivy. +1 In general, though, as we move to the build structure discussion, are you OK with using dependency management. I’m not big on putting other people’s software distributions into our source repository, especially if we’re going to see more dependencies as time goes on. Yes, i'm ok. Clearly we are not gaining critical mass where it comes to gaining interest and new blood for much needed innovations and improvements. Whe cannot let Peter do the work on his own, and the longer we let Peter work in isolation, without bringing his work into the main trunk, the worse we are of. So if we need to change things, i see the adoptition of popular tools as a way to enlist others to work on river. Gradle i view as a bit much, maven should be general knowledge nowadays. I still claim we can do without it, but if we need a popular (and therefore recocnizable feel) to increase the adoption, i'm all for it. The way it is going right now, is an agony to most i think. Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
On 12-02-14 15:56, Greg Trasuk wrote: Hi Sim, -1 votes need to have an explanation, for the archives. If it is so important to revise the build system, to me it is not, but you care a lot about it, we should view the problem on a wider scope. Why not put the effort in, to revise our whole build system? I think it is important not just change things for no reason, as this is how i view the migration to ivy. I know ivy, i use ivy, but i cannot see this as a improvement to river. Let me know if this is unclear to you, or that you do not agree with me. The one is solvable the other isnt. Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
On 12-02-14 11:28, Simon IJskes - QCG wrote: Ok, what i have seen is: - maven / gradle / ivy - convention (submodules structure) - 1 river or submodules (reedy-trasuk) Do we need to discuss this further, or do we need a vote on the sub-items. Gr. Simon in order of pref: - maven - gradle - ivy conventions: +1 submodules: +0 Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
On 10-02-14 20:50, Greg Trasuk wrote: As discussion has settled somewhat, I would like to call another vote to accept the latest patch described in https://issues.apache.org/jira/browse/RIVER-432 The patch removes the archived jar files for Velocity and ASM and replaces them with Apache Ivy scripts that download the jars from Maven Central the first time a build is done. From then on, the jar files are in Ivy’s repository (for more info, see http://ant.apache.org/ivy). Voting will remain open at least until 2000 UTC Feb 13, 2014. Cheers, Greg. -1 . -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Ok, what i have seen is: - maven / gradle / ivy - convention (submodules structure) - 1 river or submodules (reedy-trasuk) Do we need to discuss this further, or do we need a vote on the sub-items. Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
On 11-02-14 11:35, Peter wrote: We will need a new build system for java 8, this looks like a step in that direction. In reality we need to adopt the build conventions used by Rio. What are these? Maven? Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [Discuss] (RIVER-432) Jar files in svn and src distributions
On 07-01-14 14:41, Greg Trasuk wrote: Sim: Any further thoughts on the below discussion? Working on it. I'm still alive.
Re: [Vote] (RIVER-432) Jar files in svn and src distributions
In order to gain some time to discuss this first i will vote -1. First, we decided to NOT remove velocity builder. Second, no need to remove the jars as specified in your own comments on RIVER-432. Pulling in external jars at compile time, shall we start here? They are already in the svn. They are already in the build scripts. What does this patch fix? No legal problems? Pulling external jars at compile time also makes it more difficult to certify the software. In order to certify the software you need to establish baseline that will be garanteed the same, even if you pull it from the archive 10 years later. It is not a high level project that builds on several frameworks. It is a lowlevel system library. The stuff below the stack is minimal. The number of jars we use is limited. Why bother? Gr. Simon On 02-01-14 18:22, Greg Trasuk wrote: Hello all: Please have a look at the patch mentioned below and cast a vote on it. The main idea is to remove the dependency jar files from the source distribution. As a side effect of using Ivy, it becomes reasonable to remove them from the svn archive as well. Also, the Velocity dependency was there to support the VelocityConfigurationBuilder. We had discussed removing that component, so rather than move that dependency to Ivy, I’ve removed VelocityConfigurationBuilder. It’s arguable whether the VelocityConfigurationBuider was part of the official Jini API (I see it as a utility, not API), so I don’t think this commit actually requires a vote. However, it does seem like a significant change to the build process that ought to be reviewed. So I propose to treat this as a “lazy consensus” vote, and will commit the change to the 2.2 branch if there are no objections in 72 hours (i.e. 1730UTC 20140105). At the same time, based on discussions over on gene...@incubator.apache.org, I’ll withdraw my assertion that we can’t have jars in svn. Those interested may want to check out the thread at http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3C01B04CC4-95B8-4A39-BC16-04BAA4269B65%40stratuscom.com%3E Cheers, Greg. On Jan 2, 2014, at 12:05 PM, Greg Trasuk (JIRA) wrote: [ https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Trasuk updated RIVER-432: -- Attachment: river-2_2_remove_jars.diff The attached patch for the 2.2 branch does the following: - removes the 'asm' directory and 'tests/lib' directories which currently contain the asm library, mockito, and junit jars. - Modifies 'build.xml', 'common.xml', and adds 'ivy.xml' so that the Apache Ivy ant plugin is downloaded at build time, and then used to retrieve the libraries mentioned above from Maven Central. This removes the need to have the jar files in svn. - Removes (as per discussion http://mail-archives.apache.org/mod_mbox/river-dev/201211.mbox/%3C509B99E3.6080800%40qcg.nl%3E) the VelocityConfigBuilder, and associated Velocity jars. Note that the 'extras' folder is not present in the 2.2 branch, so Sim's last comments in the thread do not apply. Jar files in svn and src distributions -- Key: RIVER-432 URL: https://issues.apache.org/jira/browse/RIVER-432 Project: River Issue Type: Bug Reporter: Greg Trasuk Attachments: river-2_2_remove_jars.diff Recent traffic on the incubator lists has pointed out that including jar files for dependencies in the subversion repository and the source distributions is against Apache policy. In River, the following libraries appear in the Subversion repository and the source distributions (these are from trunk, a smaller set appear in the 2.2 branch): animal-sniffer asm bouncy-castle dnsjava high-scale-lib rc-libs velocity They all have to go. What are we using them for? As I understand it, we were going to remove the VelocityConfigurationBuilder, so that's not a problem. Some of the others are available from Maven Central, so we can get them at build time using Ivy or another build tool. Which ones are actually required? And where did they come from? -- This message was sent by Atlassian JIRA (v6.1.5#6160) -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: VOTE: add Startable to Jini specification
On 19-12-13 01:42, Peter wrote: +1 Peter. +1 Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [jira] [Commented] (RIVER-432) Jar files in svn and src distributions
I dont think the pathnames constitute a whole lot of difference in copyright terms. I think this issue revolves around having no binary products of anyone in the source distribution (the source release). I've no opinion yet on if 'tool' jars belong in a binary distribution. Gr. Simon On 19-12-13 12:10, Peter wrote: Looking at the last paragraph in Sam's email he goes on to say we can have jar files in svn for build tools etc, but not in our open source product trees. In that case the easiest temporary solution would be to move them into a designated directory outside of our product tree, then we can have ant retrieve them as needed for jenkins tests until we work out a more permanent solution. Cheers, Peter. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [jira] [Commented] (RIVER-432) Jar files in svn and src distributions
Quote from Roy Fielding: The only jar files we should have in subversion are the non-product trees -- the places where we store build tools, the artifacts for binary packages, website tools, and the dist directories themselves. They do not belong in our open source product trees. Gr. Simon On 19-12-13 02:38, Greg Trasuk wrote: There seems to be some debate about that in the incubator lists. Some people seem to think that having jars in Apache’s svn is effectively distributing them, which is counter to the foundation’s charter of producing free software in source code form. In my opinion, “if we aren’t distributing it, why would we have it in svn?”. It follows that if we can’t distribute anything but source (see footnote 1), we shouldn't have anything but source in the project’s repositories. If a jar is a valid build tool, one would assume it is available from whoever is running that project. Recent Incubator practice has been to ban binaries, since it is possible to download them at build time with Ant, Ivy, Maven, or just about any other build tool. Put another way, wearing my “PMC Chair” hat, as the one who is legally answerable to the board, I plan to delete the compiled jars from our svn trees as soon as possible, after we’ve ensured that the project can be built without them (probably using Ivy or requiring people to do a separate download of any additional tools that they might require). If anyone feels strongly that I’m acting in error, let me know and I’ll refer the question to either legal@ or board@. I believe there are one or two Apache Members on this list - perhaps someone could chime in? Cheers, Greg (1) I will confess to some confusion over how projects go about distributing binary releases - best I can make out is that these are “convenience binaries” that are the responsibility of whoever makes them, and we shouldn’t be voting on them or considering them “Apache” releases. On Dec 18, 2013, at 7:35 PM, Simon IJskes - QCG wrote: http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C0F5691A1-97C0-444F-A514-B2E4E8E907DA%40gbiv.com%3E -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [jira] [Commented] (RIVER-432) Jar files in svn and src distributions
On 19-12-13 02:38, Greg Trasuk wrote: Put another way, wearing my “PMC Chair” hat, as the one who is legally answerable to the board, I plan to delete the compiled jars from our svn trees as soon as possible, after we’ve ensured that the project can be built without them (probably using Ivy or requiring people to do a separate download of any additional tools that they might require). If anyone feels strongly that I’m acting in error, let me know and I’ll refer the question to either legal@ or board@. Yes i do. Please refer the questions: "is having something in the svn the same as distributing" and "do i need to delete all jars from svn to be compliant" to the legal@ list. Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: [jira] [Commented] (RIVER-432) Jar files in svn and src distributions
http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C0F5691A1-97C0-444F-A514-B2E4E8E907DA%40gbiv.com%3E The only jar files we should have in subversion are the non-product trees -- the places where we store build tools, the artifacts for binary packages, website tools, and the dist directories themselves. They do not belong in our open source product trees. IMHO this is about jars in the 'src release' not the 'subversion'. On 19-12-13 00:40, Greg Trasuk (JIRA) wrote: [ https://issues.apache.org/jira/browse/RIVER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13852317#comment-13852317 ] Greg Trasuk commented on RIVER-432: --- The topic came up in regards to a release of Apache Spark Incubating. I quote Marvin Humphrey from that list (http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3CCAAS6%3D7iQSKTgNdO-0Qyd3T9--%2B%2BHQFEmhJi7CHoByqvQvp9_bg%40mail.gmail.com%3E) Please read these messages from ASF Board member Roy Fielding: http://s.apache.org/roy-binary-deps-0 http://s.apache.org/roy-binary-deps-1 http://s.apache.org/roy-binary-deps-2 http://s.apache.org/roy-binary-deps-3 This has to be fixed. If some TLP PMCs have not been made aware that binary dependencies may not be bundled in source releases, the Incubator must not compound the problem by failing to educate current podlings. Cheers, Greg. Jar files in svn and src distributions -- Key: RIVER-432 URL: https://issues.apache.org/jira/browse/RIVER-432 Project: River Issue Type: Bug Reporter: Greg Trasuk Recent traffic on the incubator lists has pointed out that including jar files for dependencies in the subversion repository and the source distributions is against Apache policy. In River, the following libraries appear in the Subversion repository and the source distributions (these are from trunk, a smaller set appear in the 2.2 branch): animal-sniffer asm bouncy-castle dnsjava high-scale-lib rc-libs velocity They all have to go. What are we using them for? As I understand it, we were going to remove the VelocityConfigurationBuilder, so that's not a problem. Some of the others are available from Maven Central, so we can get them at build time using Ivy or another build tool. Which ones are actually required? And where did they come from? -- This message was sent by Atlassian JIRA (v6.1.4#6159)
Fwd: River-QA-windows build leaving zombie JVMs
Original Message Subject: River-QA-windows build leaving zombie JVMs Date: Sat, 16 Mar 2013 10:15:26 +0100 From: Niklas Gustavsson Reply-To: bui...@apache.org To: bui...@apache.org The River-QA-windows is leaving zombie JVM processes on the Windows slave and thus destroys other jobs. I have again disabled the job, do not enable it until this has been fixed. Else we'll have to delete the job all together. /niklas
Re: [Vote] Release Apache River 2.2.1 Maven artifacts.
+0 On 15-05-13 03:17, Greg Trasuk wrote: Hi all: The staging repository below contains the Maven artifacts based on the Apache River 2.2.1 release that was approved on May 3. Please review and vote for or against promoting these artifacts to released status, which will be published to Central. Cheers, Greg. [ ] +1 : I approve this release [ ] +0 [ ] -0 [ ] -1 : I do not approve this release (reasons are as follows...)
Re: [Vote] Release Apache River 2.2.1
+0 (not time to evaluate the results) On 28-04-13 14:26, Greg Trasuk wrote: Apache River 2.2.1 is a maintenance release based on the Apache River 2.2 branch, primarily with fixes that correct incompatibilities with Oracle JDK 7. This is the second call for votes. The first was cancelled due to errors found in the release notes. Candidate Artifacts are available at: http://people.apache.org/~gtrasuk/river/2.2.1-rc2/ Also at that location are text files containing the 'diff' output from release 2.2.0, and the output of 'svn log --stop-on-copy' which shows all the revisions that were committed since the 2.2.0 branch was created. Voting period will end no sooner than UTC May 2, 2013 (8:00 pm EDT Wed May 1, 2013). As per http://www.apache.org/foundation/voting, Releases require three binding '+1' votes, and more +1's than -1's. Please vote by replying to this thread on the "dev@river.apache.org" list, with the section below filled out. If not voting +1, please provide your reasons why. - [ ] +1 : I approve this release [ ] +0 [ ] -0 : [ ] -1 : I do not approve of this release (reasoning attached) Thanks in advance, Greg Trasuk. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Tests failing due to port in use
On 10-04-13 13:09, Peter Firmstone wrote: Where shall i put it? It's a single class. The qa suite package com.sun.jini.test.share looks like a good candidate. http://svn.apache.org/viewvc/river/jtsk/skunk/sijskes/SimpleJeri/Heapdumper.java?view=log&pathrev=1466426 I've no time to integrate it. Sorry. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Tests failing due to port in use
On 10-04-13 12:56, Peter Firmstone wrote: On 10/04/2013 7:46 PM, Simon IJskes - QCG wrote: On 10-04-13 09:44, Peter Firmstone wrote: I wonder if there's a way to detect RLIMIT_NOFILE from java? Other then spawning a shell with 'ulimit -n' i can't tell. In order to find the open port and do a 'lsof -i :4160' we need root access to see other userids, if whe don't have it, the result is not all-inclusive, but i suspect any jenkins build is the most likely suspect, and these i think would all run under the same userid. I also have code to create a heapdump programmatically, so if the exception occurs whe can inspect the dump later. That might also be useful for tests failing only occassionally, synchronization issues are suspected, so far it's proven quite difficult to determine causes and I've had to resort to visual code inspection. Where shall i put it? It's a single class. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Tests failing due to port in use
On 10-04-13 09:44, Peter Firmstone wrote: I wonder if there's a way to detect RLIMIT_NOFILE from java? Other then spawning a shell with 'ulimit -n' i can't tell. In order to find the open port and do a 'lsof -i :4160' we need root access to see other userids, if whe don't have it, the result is not all-inclusive, but i suspect any jenkins build is the most likely suspect, and these i think would all run under the same userid. I also have code to create a heapdump programmatically, so if the exception occurs whe can inspect the dump later. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Tests failing due to port in use
From the build list: Hi, The Apache Aries build removed ubuntu2 from its list of possible machines several months ago because its ulimit was set to 1024 while the other ubuntu machines were set to 4. Would you be able to make it match the other machines as part of the rebuild please? John I havent checked, but i believe they are talking about: RLIMIT_NOFILE might that also be relevant to failing tests? It limits the number of sockets open. When opening a socket when the filedescriptors are exhausted, all platforms provide exceptions indicating so, would they? Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Next steps after 2.2.1 release
On 09-04-13 11:44, Peter Firmstone wrote: I've never experienced the issue locally (I see it on Jenkins quite a lot), but I suspect a stale registrar process left from another test may be stopping the socket from closing. Not that registrars are also simulated for discovery tests, so it may not necessarily be Reggie. The code is duplicated in two places in superclasses of the tests that are failing, the method portInUse(int port) is supposed to check if the ports available, but only selects from a list of LookupLocator's known to have started, so doesn't actually check the port's available. Perhaps you can find the stale test process responsible? And other jobs get executed on the same machine at the same time. Maybe these consume ports? The best way to find the problem looks to me like doing a 'lsof -i' in the test as soons as a port turns out used unexpectedly. Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
wiki spam
Thanks Greg, for removing the spam from the wiki all the time. Gr. Sim -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Open discussion on development process
On 29-11-12 13:07, Peter Firmstone wrote: On 29/11/2012 10:04 PM, Simon IJskes - QCG wrote: How about the following, we develop on a branch. Then we merge or patch. We release. We pull a new branch of trunk. We merge/patch stuff that did not make it in the release from the previous dev branch into the current dev branch. (we can skip rebranching if we want to keep the old dev branch). It looks like a lot more work, but i suspect river-core will only get small changes, and the rest will end up in other subprojects. Ok, sounds like a plan. Shall i do a 'switch-and-stitch' with trunk and new dev-branch? Do you have a revision number from just before the bugfix experiments in RegistrarImpl? We could make that the new trunk. And the current trunk the dev-branch. I can do it in such a way, the revision history is kept clean. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Open discussion on development process
On 29-11-12 12:34, Peter Firmstone wrote: I'm not sure, at this point I just know we've got problems, there's a lot of coupling in the test suite and a lot of shared state; it's all based on inheritance. There are two test types: 1. Jini Standards Compliance 2. Implementation integration tests. Which errors do we want to catch by the tests? - Runtime compatibility? - Compile time compatibility? - Behaviour errors? The last one is the one we currently focus on. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Open discussion on development process
On 29-11-12 12:34, Peter Firmstone wrote: I think that's wise equally I'm pondering how you cope with trunk moving on and breaking a bunch of your tests for which there would be fixes in the trunk test suite. Are you happy doing merges as and when or ??? I'm not sure, at this point I just know we've got problems, there's a lot of coupling in the test suite and a lot of shared state; it's all based on inheritance. There are two test types: How about the following, we develop on a branch. Then we merge or patch. We release. We pull a new branch of trunk. We merge/patch stuff that did not make it in the release from the previous dev branch into the current dev branch. (we can skip rebranching if we want to keep the old dev branch). It looks like a lot more work, but i suspect river-core will only get small changes, and the rest will end up in other subprojects. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
bugs
On 29-11-12 12:34, Peter Firmstone wrote: Oh, BTW, when I turned off debugging I had 6 tests fail, then after running again only 2 tests failed; my recent patches haven't solved concurrency issues, debugging masked it. Sorry to hear that. I've seen a failure in discovery on a number of occasions, any change this could be related to the bug your fixing? -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Open discussion on development process
On 28-11-12 15:49, Dan Creswell wrote: I'd like to be able to run an experimental test suite with a stable River trunk to test the test suite so to speak. I think that's wise equally I'm pondering how you cope with trunk moving on and breaking a bunch of your tests for which there would be fixes in the trunk test suite. Are you happy doing merges as and when or ??? Are we talking here about an experimental test suite, in the sense of a completely parallel testsuite, or an experimental change to the test suite? 2 test suites look a bit much to me. And when the separate experimental suite is of benefit, it could be integrated making it one again. An experimental change to the testsuite, if proven, could be merged/patched into trunk at the same time the shared skunk (shall we call if dev-branch or so?) is merged. Gr. Sim
Re: Open discussion on development process
On 28-11-12 15:17, Peter Firmstone wrote: It would be nice to have a stable qa suite branch for testing River development and another for refactoring and developing the test suite itself, without interfering with the development process of River. The test suite requires maintenance too, but right now it's a frightening prospect. So this would mean we should reduce the coupling between the subprojects. We could start by giving it separate directories: /river-core (old jstk) /river-core-test (old qa) something like this? -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Open discussion on development process
On 28-11-12 14:40, Peter Firmstone wrote: Can we have a shared skunk branch? At present we each have our own skunk branches. Good idea. Lets try it. I think that what Sim was trying to achieve was a more cohesive collaborative approach by developing in trunk, I think we could have that with a shared skunk development branch. Indeed, but this new idea of yours works has more benefits. At stable points the skunk development branch can replace trunk. We might have a period of refactoring and bug fixing, followed by a period of stabilisation, testing and documenting, before replacing trunk, then branching off a release. I would patch or selectively merge from skunk to trunk in this case. I'd also like to see the qa test suite broken out and managed separately, this would allow the same test libraries to run against both skunk development and trunk branches. Please explain some more. Gr. Sim -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: RegistrarImpl
On 27-11-12 13:08, Dan Creswell wrote: More importantly though, do you guys feel like you're having a positive conversation here? Yes i do. We cannot always give another unqualified praise. But just the fact that there is conversation, is already so much better then no conversation, that i see some occasional outburst of either party as a nescessary artifact to work on the exceptional difficult project like this. With some much conflicting interests, agendas, styles and such a mature codebase, it will unavoidable have it some periods that things are not exactly pleasent. And please don't make the mistake, that everytime i raise an issue, it sit behind my PC singing, and enjoying it. To quote JFK: "We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard,.." -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: RegistrarImpl
On 27-11-12 12:58, Peter Firmstone wrote: When faced with difficult concurrency problems, I've had success in the past by refactoring. Trouble with concurrency bugs; you can't always tell where they are, consider it a brute force debugging attempt, sometimes it pays off. Correct. You are right. If you prefer ReggieImpl how it was previously we can change it back after all tests are passing. I see valuable things, like the generics, which i would like to keep. The guarded collections only if needed, and volatile less of a problem. The lock/TODO stuff needs to go IMHO. Network stuff needs inspection. Reordering threat startup, only if confirmed by other team member. The only thing i'm worried about, with these 'big' changes are the small changes in behaviour that cause problems in existing installations. What do you do in these cases, leave the old version, and never improve? Or put in the new version with exposing subtle bugs? If somebody else on this list would say, i can wholeheartedly support the changes and it only became more solid. It can stay the way it is. To be honest, i don't have the time to do a torough code inspection, so i'm a bit on the conservative side right now. My opinion. Gr. Sim -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
RegistrarImpl
I see a lot of changes to RegistrarImpl. Was RegistrarImpl really that broken? What errors have been fixed by moving the places the threads were started? What errors have been fixed by converting the collections, and making variables final? What errors have been fixed by changing the Socket handling? Gr. Sim -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: svn commit: r1412436 - /river/jtsk/trunk/qa/src/com/sun/jini/qa/harness/MasterHarness.java
On 22-11-12 14:41, Peter Firmstone wrote: On 22/11/2012 8:22 PM, Simon IJskes - QCG wrote: On 22-11-12 11:16, Dan Creswell wrote: See, if it wasn't on trunk, the changes would be less of a big deal. It'd be natural to check one's work in (whether it be an in-progress test snapshot or otherwise), good discipline even. Yes. I would have branched trunk, copied a jenkins job, and experimented on it. If something good would come out of it, it would probably be small, and easily patchable on trunk. I might remind you Sim, that recent evidence demonstrates you didn't make this choice. Ok, if even so, intentional or not. We talk about things in retrospect. If you cannot endure critisism, i suggest that you find some other way to educate yourself. If i may point out, your emails are way to verbose for me. If you want to enlist my help, to function as a team, i would suggest to entice others to follow your dreams by way of smaller steps, allowing others to chime in, and more important to allow others to have some influence. All in good faith, Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: svn commit: r1412436 - /river/jtsk/trunk/qa/src/com/sun/jini/qa/harness/MasterHarness.java
On 22-11-12 11:16, Dan Creswell wrote: See, if it wasn't on trunk, the changes would be less of a big deal. It'd be natural to check one's work in (whether it be an in-progress test snapshot or otherwise), good discipline even. Yes. I would have branched trunk, copied a jenkins job, and experimented on it. If something good would come out of it, it would probably be small, and easily patchable on trunk. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: svn commit: r1412436 - /river/jtsk/trunk/qa/src/com/sun/jini/qa/harness/MasterHarness.java
On 22-11-12 10:58, Dan Creswell wrote: I have a different question: Is this really being done on trunk and, if so, why? Indeed. I wouldn't have done this on trunk. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: svn commit: r1412436 - /river/jtsk/trunk/qa/src/com/sun/jini/qa/harness/MasterHarness.java
On 22-11-12 10:18, Peter Firmstone wrote: I tried SO_REUSEADDR on an earlier attempt, that didn't work either, that was a hack too. In general, i do not consider SO_REUSEADDR a hack. It is a perfectly permissable construct for servers. The real fix will is to have the client close the port, rather than the server, but since I don't have direct access to this box, I can't really tell if that's the actual problem or if those ports aren't available at all. You cannot dictate the behaviour of a client. So any solution needs to be robust enough, to behave correctly independent of the client. TCP is such a solution. There are problems with the TCP protocol, exploited by malicious parties, but they are not manifesting themselfs in the test environment. So we could have a number of possible causes: - incorrect assumptions or bugs in the java program. - bugs in the java VM Socket implementation. - bugs in the TCP stack. There are a number of instances where an interrupt is not triggered in some system calls. Therefore a plausible cause is ServerSockets that are not really interrupted. Or not closed by java instances of ourselfs not correctly terminated. You could try to make a class, that reports with the use of the 'netstat' program which ports are in use and what status they have, to be triggered at the problem points. I can help you with that, but only if you stop making those 'just try' patches, and with improved communication (improved in quality, not verbosity). Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: svn commit: r1412436 - /river/jtsk/trunk/qa/src/com/sun/jini/qa/harness/MasterHarness.java
On 22-11-12 07:45, peter_firmst...@apache.org wrote:
+try {
+Thread.sleep(24); // Wait 4 minutes for TCP 2MSL
TIME_WAIT
Peter,
could you please try to explain why you are removing SO_REUSEADDR and
introducing this wait-retry?
Please speculate about the potential bug you think there is.
Is it a desperate attempt? Or have you found a solid theory behind it?
Gr. Simon
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: LookupLocator
On 14-11-12 13:52, Peter Firmstone wrote: I'm familiar with the ConstrainableLookupLocator code, I could knock it up for you in about 10 min, I actually did this when I realised the SocketFactory in LookupLocator wasn't being used by LookupLocatorDiscovery or ConstrainableLookupLocator, then I looked at it again and thought this looks wrong because it couldn't be instantiated during multicast discovery, I could see what the intent was though, hence the list questions. You've clearly looked much deeper than me, ok, i'm happy with the state right now. Thank you for the time you have put into explaining it all. Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: LookupLocator
Whereever a Socket or ServerSocket is created i want to have the option of intercepting this call. Based on this, and this seems like the simplest option, and the code was already there, i was against. I havent looked at in depth. I believe you, if you say this intercept can be done with an extended class. But why remove working code? As to security, nothing is less secure as a TCP connection, so i view unicast (tcp based) discovery as a unsecure process anyway. The proof is in the TLS between endpoints. I don't need it right now, but i will be very unhappy, when i need a lot of extra work, the moment i need it. So if it doesnt harm, can we leave it in (the factory, not the rest)? Gr. Simon On 14-11-12 13:24, Peter Firmstone wrote: Is it possible for you to subclass LookupLocator and override the getRegistrar method? Alternatively you could subclass ConstrainableLookupLocator and subclass com.sun.jini.discovery.internal.MultiIPDiscovery, this is far simpler to implement and would allow you to inject a socket into ConstrainabledLookupLocator and use Discovery V2 or V1. This could be done cleanly without making LookupLocator more a cludge than it is already. Discovery V1 used by LookupLocator was upgraded in Jini 2.0 with Discovery V2 in LookupLocatorDiscovery and ConstrainableLookupLocator. How badly do you need it? Regards, Peter. On 14/11/2012 9:45 PM, Simon IJskes - QCG wrote: On 14-11-12 11:50, Peter Firmstone wrote: Reading over the comments, we all appear to be agreeing on Gregg's approach, in that case I'll clean up LookupLocator before release, then we can look at how we can implement a configurable deployment mechanism. I was against removing the SocketFactory. Please revert. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: LookupLocator
On 14-11-12 11:50, Peter Firmstone wrote: Reading over the comments, we all appear to be agreeing on Gregg's approach, in that case I'll clean up LookupLocator before release, then we can look at how we can implement a configurable deployment mechanism. I was against removing the SocketFactory. Please revert. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: LookupLocator
On 14-11-12 10:49, Dan Creswell wrote: Which implies a socket factory isn't required because there's only one way to "do" unicast and it's all taken care of under the covers. A socketfactory is also the place to post process Sockets [1]. So if you want to keep Socket, there is no reason to do away with SocketFactory. [1] javax.net.SocketFactory javadoc: "So for example, factories could be customized to return sockets with different networking timeouts or security parameters already configured." -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: LookupLocator
On 14-11-12 03:57, Gregg Wonderly wrote: Of course, the practical matter, is that in this day and age, server port numbers indicate specific types of services for the things in /etc/services. But, really, we should move the whole discovery business away from "socket creation parameters" and into a "mechanism" using an interface or abstract class so that through Configuration, it would be pluggable at deployment. Not only this, but whe should create an abstract transport layer under jeri, with a bidirectional stream (similar to a socket). Communicating endpoints could be done with URI instead of serializing transport specific endpoints. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: LookupLocator
On 13-11-12 14:31, Peter Firmstone wrote: Oh I found a bug in LookupLocator on ARM btw: Ok, we should leave the ARM port for the next release then. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Lookup service failures on ARM
On 11-11-12 12:08, Peter wrote: Thanks Sim, I haven't tried that, I won't get to try for another 24 hours, in case you wan't to experiment with it in the mean time. No, sorry. The problem is all yours. Gr. Simon -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Lookup service failures on ARM
On 10-11-12 22:41, Peter Firmstone wrote: I'm trying to solve failures on the ARM platform, for now I've changed the Reggie ServerSocket to wait for 4 minutes for the TCP TIME_WAIT period then retry, unfortunately the port is still in use after waiting, which tends to indicate a stale process. Thank you, the problem is much clearer now. Have you tried to open a connection to localhost:port and closing it immediately thereafter, on first BindException? It is a dirty workaround, but can nudge a waiting accept to process a pending interrupt. If you are worried that it might stall, this connect, you can start an extra thread for it.
Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java
On 10-11-12 21:53, Peter Firmstone wrote: It's set to true for most Unix platforms, as far as I'm aware. If the client side remotely closes the ServerSocket, then there's no TIME_WAIT period, it's only when the ServerSocket is closed by the server. I'm kinda stretched for time right now, I'll go into more depth for you later this week if you need me to. Oh yes. I'm excited to hear your explanation. maybe this will help with your explanation: http://hea-www.harvard.edu/~fine/Tech/addrinuse.html Gr. Sim
Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java
On 10-11-12 12:51, Peter Firmstone wrote: Why did you not use ServerSocket.setReuseAddress(true)? 3. You can't reconnect to the same remote TCP IP address during the TIME_WAIT period. Which caveat are you refering to? TIME_WAIT? You mean at the client side? Shouldnt the client get an ephemeral port for the next connection? This new port number ensures a unique association 5-tuple. (Stevens, 1990, Unix network programming, Section 5.2) I've never had problems with SO_REUSEADDR! It is in use for EVERY server bound to a fixed port on this planet, isn't it?
Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java
On 10-11-12 12:51, Peter Firmstone wrote: Why did you not use ServerSocket.setReuseAddress(true)? 1. It's platform dependent and causes issues on windows platforms. Bold statement. Which issues?
Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java
On 10-11-12 11:32, peter_firmst...@apache.org wrote: Author: peter_firmstone Date: Sat Nov 10 10:32:46 2012 New Revision: 1407747 URL: http://svn.apache.org/viewvc?rev=1407747&view=rev Log: Enable Reggie to handle a ServerSocket caught in the 4 minute TCP 2MSL TIME_WAIT state, can be safely interrupted. Why did you not use ServerSocket.setReuseAddress(true)? This will hamper discovery after quick restart of a vm wouldn't it? Gr. Simon
Re: RiverClassLoaderSPI
On 10-11-12 00:07, Peter Firmstone wrote: tried developing experimental code directly in trunk unsuccessfully. I think we need to clarify our development processes. Lightweight. Only commit code that compiles. (s)he who breaks the build fixes the build. idem testing. No jumbo patches. No jumbo emails. Enlisted sponsor/fan of at least 1 other person for your ideas. sub projects can have skunk, beta, mature, any status based on concensus. river-core modifications are driven by requirements from sub projects only.
Re: RiverClassLoaderSPI
On 09-11-12 13:48, Peter Firmstone wrote: Simon IJskes - QCG wrote: On 09-11-12 00:31, Peter Firmstone wrote: Ok, because it's small I think we can consider it, can you provide the hooks to load different providers? The non default providers themselves can be a subproject. We need to carefully consider security since we're making it possible for downloaded code to resolve classes. And this one? Do you want me to code hooks (spi?) in river-core so that subprojects can attach? I was basically saying in a very roundabout way that skunk has its place, for more complex changes. Or develop without intermediate commit, or run synced clone, or work with own codebase, and reintegrate after proven use. Everything is possible. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: RiverClassLoaderSPI
On 09-11-12 13:49, Peter Firmstone wrote: Simon IJskes - QCG wrote: On 09-11-12 11:44, Peter Firmstone wrote: Motivated by Sim's suggestions: Any objection to changing it to net.jini.io.MarshalClassResolverSPI? Leave it near net.jini.loader.ClassLoading. I would have implemented it in ClassLoading if i wasn't concerned about leaving mature classes untouched. Ok. RiverClassLoading(Spi) ? ClassLoading2 & ClassLoadingSpi ? JiniClassLoading(Spi) ? -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: RiverClassLoaderSPI
On 09-11-12 11:44, Peter Firmstone wrote: Motivated by Sim's suggestions: Any objection to changing it to net.jini.io.MarshalClassResolverSPI? Leave it near net.jini.loader.ClassLoading. I would have implemented it in ClassLoading if i wasn't concerned about leaving mature classes untouched. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: RiverClassLoaderSPI
On 09-11-12 00:31, Peter Firmstone wrote: Ok, because it's small I think we can consider it, can you provide the hooks to load different providers? The non default providers themselves can be a subproject. We need to carefully consider security since we're making it possible for downloaded code to resolve classes. My SecurityManager and policy providers were developed in skunk, then merged. URI changes were made in trunk, although this was a big change semantically, the code footprint is small. For large changes to foundation code we need skunk, not everything can be bolted on or plugged in. I have difficulty understanding what you are talking about. Could you try again? Gr. Simon
Re: proposal: removal of velocity related o.a.r.config.builder
On 08-11-12 21:33, Tom Hobbs wrote: From memory, the stuff I put into the "extra" source folder uses Velocity to build a kind of fake in-memory ConfigFile which allowed easy configuration via plain old Java code. I'd check it, but you'll probably have to ditch that as well. Ok, i will not delete, and possibly refactor into configFile with specialEntry overrides for variables.
Re: RiverClassLoaderSPI
You are probably aiming at a scheme based dispatching of classloader URI. Cool feature! Shall we put this in an implementation of RiverClassLoaderSpi? i meant, deriving, extending.
Re: RiverClassLoaderSPI
On 08-11-12 13:40, Peter Firmstone wrote: Yes, but lets play around with it in skunk. Dan's made some valid Indeed Dan has made valid remarks, but i really dont like skunk. Tom suggested sub projects once. I did not see any benefits at that time. But i think it might be helpful right now. We could use the subprojects as 'clients' to the core, and allow requirements of these subprojects drive the modifications of the core. We can decide whatever status a subproject will have, and we do not make them heavyweight. Just an extra jar, an extra libs and an extra src in a directory together. I'm thinking about osgi, wan, internet, jmx transports etc. We treat the sub projects as first class citizens, and do proper release management on them. Just not that often. Am i still thinking too grandiose Dan? Gr. Simon
Re: RiverClassLoaderSPI
On 08-11-12 12:19, Dan Creswell wrote: I don't want to be harsh but as a group we seemingly spend a lot of time thinking about all sorts of cool things we could do given we've already done this or that other thing. How about we do a few small steps in some promising (like valuable to our community not just individual developers' needs) directions and then see what's what. To do otherwise runs risk of having an even bigger, more complex to manage and understand codebase with lots of configuration and customisation - to what value? We have meagre resources, we're very ambitious but we seem to undo the horsepower we have by going very wide and very deep, is that good? Good writup, we probably differ in scope and direction.
proposal: removal of velocity related o.a.r.config.builder
Any objections to removal of the VelocityConfigurationBuilder? To be honest, i hate it. It was build to merge runtime determination of constants, and the posibility to step up to completly text driven configuration, but i'm much more happy with a specialized ConfigurationFile with overrides for getSpecialEntryType(); Gr. Simon P.S. if there is interest i will commit described approach.
Re: RiverClassLoaderSPI
On 08-11-12 11:51, Peter Firmstone wrote: For example using another string annotation in MarshalOutputStream might allow selection from a list of providers in a mixed environment? You are probably aiming at a scheme based dispatching of classloader URI. Cool feature! Shall we put this in an implementation of RiverClassLoaderSpi? schemes like: maven:, system:, http:, codeservice: spring to mind.
Re: internet version
On 02-11-12 09:12, Bishnu Gautam wrote: Hi Simon Thats sounds great. Please upload the code in the river and also provide the documentation. Your solution is pretty exciting. RegardsBishnu Bishnu, Do you have a project in mind where you want to use the mekong code? Gr. Simon
Re: internet version
On 29-10-12 11:24, Dan Creswell wrote: On 29 October 2012 10:15, Simon IJskes - QCG wrote: On 29-10-12 09:11, Dan Creswell wrote: That's not to say I'm down on the above at all, far from it. Rather I'm saying we'd need to look seriously at our deployment aspirations, the sources for services (do we really need third party services separately certified? Most banks take a different approach where they certify third-party code themselves) and the general "market-place" we wish to create. Wouldn't the problems be solvable if we only focus on closed user groups connecting over the internet? Quite possibly - question is, who is that useful to and are they a "usefully large" chunk of audience? Developers of applications that need internet wide communication, and jini services combined. I'm not talking about a 'eco-system' of jini clouds, i would be very happy if there are a few applications that are capable of communicating jini style over the internet. Even without these few cooporating in a greater system. Chat applications, Remote sensor networks, Location updates, Voting systems, anything that require realtime, retractable facts to be communicated over the internet. Gr. Simon
ServiceDiscoveryManager behaviour
I have a question as to the behaviour of ServiceDiscoveryManager. When i create a lookupCache with a ServiceDiscoveryListener in the constructor, very seldom i miss a ServiceAdded event for a service that is discovered, while another lookupCache created with the same ServiceDiscoveryManager but earlier, with a ServiceDiscoveryListener in the constructor, does get a ServiceAdded event for the service. I've tried to find a definition of this behaviour, but cannot find it. Does the SDL get a serviceAdded event for every service discovered, or do i need to read the lookupCache at construction time and generate the events myself? Reading the docs of LookupCache.addListener() i suspect some race condition in creating the lookupCache. Have others had this occur as well? Maybe due to transient network errors? As a sidenode, shall we ensure the QA build is run on a multi-core machine? In order to expose those possible race conditions?
Re: [VOTE] Elect New PMC Chair
+1 On 06-11-12 21:43, Tom Hobbs wrote: Vote for Greg Trasuk to be the new defacto PMC chair +1 - Vote for Greg 0 - Don't mind -1 - "Not Greg because..." or "X should also be nominated and a vote re-called"
Re: [DRAFT][REPORT] Apache River
On 04-11-12 22:47, Tom Hobbs wrote: Comments always welcome, due date is 14th November. Below is the November board report for River Apache River is a distributed computing architecture, based on the JSK Starter Kit Source code donated by Sun Microsystems, for the Jini Specification. Releases: No new releases since last report. Some failing unit tests are the only blocker to release right now and they are being investigated. Progress: Some more interesting discussions are taking place about some directions River might take and what it's going to do next. There have been some commits and we're looking again at getting ready for another release. There has been some frank and open discussion which the PMC dealt with well and we feel that we're acquitting ourselves well. Community: The PMC chair has requested that the PMC/community elect a new chair, citing external commitments preventing him from being able to devote sufficient to River. The board should expect this change to happen soon. Issues: No board issues at this time +1
Re: PMC Chair: was: Re: [DRAFT][REPORT] Apache River
On 05-11-12 00:06, Greg Trasuk wrote: Hello all: I'm willing to stand as a candidate for PMC chair, if no-one else has a burning desire. +1
Re: Failing tests
On 02-11-12 11:15, Peter Firmstone wrote: Ok, found the problem, there's a bug on line 99 in net.jini.loader.RiverClassLoader You didn't really test this properly did you? No biggy. Too busy to help any further (2 hour road trip now). Peter. Oh you are good! Thank you! Now we are getting somewhere. Gr. Simon
Re: Failing tests
On 02-11-12 11:06, Peter Firmstone wrote: Ok I've had a brief look at debugging failing tests, it's worth noting that these tests now failing on my machine, passed two months ago with flying colours. I remember something different, and as your are implying it is due to changes after your patches, please mention me a revision number where you have completed the uri patches, and i will branch on this revision number and run the tests again, to verify if your statement is true. And of course, if any of my patches are causing the tests to fail, i personally will fix them. Because that is how one should operate: No code commits that cause failing tests, or fix the tests. Gr. Simon
Re: internet version
On 29-10-12 00:58, Gregg Wonderly wrote: Clearly providing a proxy connection manger which becomes the "hub" of the entire mechanism can create more problems then the single problem that needs to be solved with NAT traversal or other network routing. I think you misunderstand the concept i'm working on. There is no single hub. Multiple MkProxy host, can host multiple MkAcceptors. One server socket behind the NAT can open multiple MkAcceptors. The MkProxy can execute all kind of policy rules which could for instance limit the load or the number of connections it hosts. As a MkProxy is just a plain river service, one can discover all the MkProxies in a djinn. There is no problem with registring a plain endpoint based service to an outside reggie from behind the NAT, when the eventlistener callback is running on a mekong endpoint. It has a similar pattern as a TURN based solution, only completely based on jini rpcs. I hope all is clear now, and if not, please ask questions. I've covered all the issues that you raised already in the code. If you have other concerns please let us know. Gr. Simon
Re: Next Release (PING)
On 01-11-12 14:35, Gerard Fulton wrote: Sounds like the tests might need to be refactored. Indeed. Or a revert of the patches causing the tests to fail. Gr. Simon
api vs impl
What do we consider api and what implementation? As a test i've tried to compile only net.jini.** , and it was not possible without errors. It could be due to javadoc comments, but before i test this by stripping the javadocs, removing the unused imports, i want a clear definition what should be the API within river. Gr. Simon
Re: Next Release (PING)
On 28-10-12 15:47, Simon IJskes - QCG wrote: On 28-10-12 15:45, Simon IJskes - QCG wrote: On 28-10-12 15:43, Tom Hobbs wrote: Can someone refresh my memory, please? I recall a few months ago we were talking about gearing up for a release. Is there any reason why we can't cut one now-ish? none. go for it! Although, what do we do with the failing tests since the URL->URI commits?
Re: internet version
On 29-10-12 11:24, Dan Creswell wrote: Quite possibly - question is, who is that useful to and are they a "usefully large" chunk of audience? No point in solving a problem that no one is interested in Exact. But it is a revolutonairy idea, isnt it? I mean, in the time of servers. clouds. information centralisation? In order to have it working for normal users, they need to let their PCs run all the time. I see a good business case for actual sensor data and management. Less for data information services run by user desktops.
Re: internet version
On 29-10-12 09:11, Dan Creswell wrote: That's not to say I'm down on the above at all, far from it. Rather I'm saying we'd need to look seriously at our deployment aspirations, the sources for services (do we really need third party services separately certified? Most banks take a different approach where they certify third-party code themselves) and the general "market-place" we wish to create. Wouldn't the problems be solvable if we only focus on closed user groups connecting over the internet? Most if not all of the problems i see are from situations where you lose control. Some implementations would create an enormous mess if left unmanaged. But we shouldn’t scope it so big in the first place. It's to big a chunk.
Re: internet version
On 29-10-12 00:58, Gregg Wonderly wrote: Clearly providing a proxy connection manger which becomes the "hub" of the entire mechanism can create more problems then the single It can, but these problems can be mitigated. The problem with most network applications is that they don't have an automation system to keep trying to connect, or find a different route, because the internet routing mechanisms are like "hidden streets", or perhaps more like unnamed streets. Thats the beauty of the connectionManager in jeri, it does the reconnecting for you. The 'routing' is done by a registry containing a list of 'accepting proxies' and a list of 'willing proxies'. It is complicated by the fact that NAT was invented instead of switching to IPV6 to get more addresses. It's compounded and perhaps never going away, because NAT turns out to provide a convenient firewall. NAT is never going away. I agree, or not in the foreseeable future. Inbound firewall blocking will stay for even longer. I think that in the end, we should really focus on "continually connected", "bi-directional flow" sockets so that callbacks can happen on those, instead of requiring a "reconnection". The client should maintain the connection to the server. Sure, you could just connect to a proxy/relay hub too. Mekong v2 is a continually connected conveyer belt, conveying i/o packets up and down. The connectionManager from jeri, will attempt a new connection, when connection is lost. It restarts by looking up the proxy that waits for the connection. So mekong has all the aspects you mention in the last paragraph.
Re: internet version
On 28-10-12 19:20, Gregg Wonderly wrote: Typically, not having two way TCP connectivity makes it harder to get Jini to work "completely right", but it's not required if you do somethings differently at the client, such as polling the LUS and Why should we do without twoway connectivity? Notification work just fine over the internet. Without the twoway connectivity you cannot offer services when you are behind a NAT router. For me this is fundamental property of internet river. To be able to offer services, to other clients, even when you are in a different LAN is an absolute requirement for me. When the client needs to use a service, look it up again rather than using notifications to know that it is still available. Notifications I have very good results with a retrying proxy, that queries the discovery manager, as soon as the original proxy is lost. Peter (and others over the past 15 or so years, but he is the most recent champion of this) has talked about internet service location Services (maybe ServiceRegistrar, but not necessary to be so). The I know from my own experience, that he is not the only one. I'm trying to pull a dead horse in this group, and interest is very low. Maybe this thread will change that. realistically with those kinds of results. Finding the right service, I think, is a hugely more narrowed search, and instead, is more than likely only a "hostname to IP address discovery" using DNS, and then MAYBE, a few "Item"s of look up context for version, locale or other very concrete needs. Grand ideas, but shall we start a bit smaller? A small non-public cluster of cooperating services? We can gain experience, and later change the way we find services. What I feel the larger issue is, generally, is that people don't know enough about networking to use Jini in a WAN environment, because they just know about port 80 based hacks for firewall traversal, and how to configure specific routers to do that. If you really understand We should not confront users with networking problems, or configuration, this would kill interest in river by developers of the end user services. routing, VLANs and ports/NAT, you typically can make the "connection" to the other end. Then, it just becomes and issue of "authentication" and "authorization" to use the service on the other end right? With a proxy host on the internet, we can have zero-setup inbound connections. No need to worry about that. Gr. Simon
Re: Next Release
On 28-10-12 15:45, Simon IJskes - QCG wrote: On 28-10-12 15:43, Tom Hobbs wrote: Can someone refresh my memory, please? I recall a few months ago we were talking about gearing up for a release. Is there any reason why we can't cut one now-ish? none. go for it! Although, what do we do with the failing tests since the URL->URI commits? -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Next Release
On 28-10-12 15:43, Tom Hobbs wrote: Can someone refresh my memory, please? I recall a few months ago we were talking about gearing up for a release. Is there any reason why we can't cut one now-ish? none. go for it! -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: com.sun.jini.reggie.Registrar
On 27-10-12 19:08, Gregg Wonderly wrote: What is your motivation to ask this question? Gregg On Oct 24, 2012, at 7:08 AM, Simon IJskes - QCG wrote: Does anybody have a problem with making com.sun.jini.reggie.Registrar public? I wanted to build a monitor/prototype for some experimentation, around Registrar.notify(), and noticed i couldnt because of the package private access.
Re: internet version
On 25-10-12 18:55, Gregg Wonderly wrote: - are you interested in river running on the internet? On a TCP/IP network at large, yes. The internet has some certain connotations that I am not sure how to quantify. 1. Do we mean everyone is untrusted and securing endpoints implies no downloaded code? >... Why did you ask these questions, by the way?
