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
