Is there a specific reason to avoid modularizing the source folders if we are modularizing the jars?
In my experience, one big source tree leads to unwanted module dependencies, and can lead to circular module dependencies, which render the modulization moot anyway... (note I am not saying to go to m_v__ as a build tool, just to keep module source code in separate trees so that intra-module dependencies can be controlled... Of course I believe that other build tool is good at helping, but if you've ever seen one of peter reilly's ANT builds you'll know it can be done easily and beautifully in ANT... Admittedly he is on the ANT pmc ;-) ) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Dec 2010 20:17, "Ryan King" <r...@twitter.com> wrote: > On Wed, Dec 22, 2010 at 11:07 AM, matthew hawthorne > <mhawtho...@gmail.com> wrote: >> hello, >> >> I'm starting a project at my day job to deploy a gossip protocol >> implementation. part of my initial work is to evaluate existing >> implementations. >> >> being loosely familiar with Cassandra, I read >> http://wiki.apache.org/cassandra/ArchitectureGossip and have looked >> over the related code a bit. >> >> is there interest in breaking out the gossip-related portions of >> Cassandra into a library that could be reused by other projects? I >> work on a team that is ready and willing to contribute heavily. we'd >> just need some guidance as to how to structure the Cassandra >> subcomponent(s) and properly integrate them with the builds, tests, >> etc. > > I think breaking gossip out could be very valuable. Gossip is a > somewhat under-understood and under-tested part of Cassandra. > Isolating it could help both of those situations. Ideally we'd not > change the normal build procedure for cassandra, but add a new target > for building a gossip library. > >> here are a few examples of functionality we're looking to add: >> >> 1) hierarchical state - our use case is cross data center gossip, >> where we don't want every node in the 2 clusters communicating, but do >> want a node from cluster1 to send a summary of the cluster's state to >> cluster2, and vice versa. essentially I'm talking about rolling up >> the state of multiple nodes into a single "virtual" node > > I'd be interested in seeing the analysis here. There are some > challenging problems with having only one host do something in a > gossip based system. > >> 2) mutual authentication - nodes verifying the identity of other nodes >> before gossipping >> >> 3) encryption - encrypted traffic, especially for the cross data center case >> >> any opinions on this? thanks in advance for any feedback! > > -ryan
