I can chime in on that part Joe. The counters weren't the reasons for launch issues. It was just actually the volume of messages we were trying to handle in the cluster, so it didn't matter if it was reads for counts or reads to normal CFs, we just had more on the count side.
It is very unfortunate that it has come down to forking on Github. Digg is in the same position as Twitter on this one. We really do depend on 1072, it's now an integral part of our requirements. We have already felt the pain of trying to keep up with 1072 in our 0.6 branch. I really hope we can come to a conscious on this because I am afraid Digg might have to use Twitter's fork as well. My two cents on the issue is that, it's an important feature that the community wants, and the work needing to be done to let 1072, isn't worth the amount of effort to delay at this stage. I would much rather get the code in, support the feature and work towards refactoring a better design than completely stalling the feature. -Chris On Sep 24, 2010, at 8:11 AM, Joe Stump wrote: > > On Sep 24, 2010, at 8:01 AM, Jeremy Hanna wrote: > >> Hmmmm... would there be any way that others in the project that are >> familiar with the design could help the authors to redo some of the elements >> to remove the internal clock structure and get it to work properly before >> 0.7.0 is finalized? Not sure if that's feasible, but I would just hate to >> see *unreconcilable* differences :). > > The Digg folks can chime in, but my understanding is a large part of the > issues during launch was the vector clock / increment patch they had deployed > internally. It fell over. My understanding is it was replaced by Redis. > > I don't know enough about the issues around the counters patch, but this is > definitely high on SimpleGeo's needs list. > > --Joe
