1200 ET, btw - bad math. All the best,
John Blossom email: jblos...@gmail.com phone: 203.293.8511 google+: https://google.com/+JohnBlossom On Tue, Jul 23, 2013 at 9:53 AM, John Blossom <jblos...@gmail.com> wrote: > OK, the consensus time/date for the hangout seems to be Wednesday, 31 > July, 1600 UTC (1000 EDT). I will create and event later today in Hangouts. > If you're on the wave-dev list and have a Google login, please forward me > your email ID/Google+ ID privately and I will add you to the circle of > invitees. I Have Joseph's ID already and I believe Ali and Michael also, > but if you have a doubt, just send it along. If you don't make the hangout > itself, I will be sure to share the link here for the common record. > > All the best, > > John Blossom > > email: jblos...@gmail.com > phone: 203.293.8511 > google+: https://google.com/+JohnBlossom > > > On Thu, Jul 18, 2013 at 9:06 AM, John Blossom <jblos...@gmail.com> wrote: > >> Ali, >> >> New tool for me, but worth a try. Here's the Doodle link: >> http://doodle.com/5z7usamgh7kee4gf >> >> I am open to other times, but these seem to be the most logical. Please >> remember that UTC at this time of year is one hour less ahead from the U.S. >> time zones due to Daylight Savings Time - e.g., ET is UTC+4 right now. >> >> All the best, >> >> John Blossom >> >> email: jblos...@gmail.com >> phone: 203.293.8511 >> google+: https://google.com/+JohnBlossom >> >> >> On Wed, Jul 17, 2013 at 5:57 PM, Ali Lown <a...@lown.me.uk> wrote: >> >>> I agree that another hangout sounds fun. >>> >>> John, how about setting up a Doodle for us to mark some dates on? >>> (http://doodle.com/) >>> >>> Ali >>> >>> On 17 July 2013 15:33, John Blossom <jblos...@gmail.com> wrote: >>> > Great, Michael, find a date that works for you that seems to match with >>> > others' interests and I will be glad to arrange for this. We can have >>> the >>> > link available but not make public, if that helps to encourage >>> constructive >>> > participation. >>> > >>> > All the best, >>> > >>> > John Blossom >>> > >>> > email: jblos...@gmail.com >>> > phone: 203.293.8511 >>> > google+: https://google.com/+JohnBlossom >>> > >>> > >>> > On Wed, Jul 17, 2013 at 10:30 AM, Michael MacFadden < >>> > michael.macfad...@gmail.com> wrote: >>> > >>> >> I am definitely interested. I will check my schedule for next week. >>> >> >>> >> ~Michael >>> >> >>> >> On 7/16/13 11:02 AM, "John Blossom" <jblos...@gmail.com> wrote: >>> >> >>> >> >That was my thought, also. ApacheWavers, please respond with some >>> avails >>> >> >calibrated to UT+1 for this week and next week. Time to get this >>> party >>> >> >started! My L,A. project is waiting for the funder to come through, >>> but my >>> >> >Nkommo project is gaining steam - hopeful that we'll have some >>> exciting >>> >> >announcements fairly soon. Time to change the world with Wave!!! >>> >> > >>> >> >All the best, >>> >> > >>> >> >John Blossom >>> >> > >>> >> >email: jblos...@gmail.com >>> >> >phone: 203.293.8511 >>> >> >google+: https://google.com/+JohnBlossom >>> >> > >>> >> > >>> >> >On Tue, Jul 16, 2013 at 1:58 PM, Joseph Gentle <jose...@gmail.com> >>> wrote: >>> >> > >>> >> >> I've had a busy few weeks - gearing up to launch our product at >>> work. >>> >> >> We should organize another hangout sometime. >>> >> >> >>> >> >> -J >>> >> >> >>> >> >> On Sat, Jul 13, 2013 at 7:24 AM, John Blossom - Shore >>> Communications >>> >> >> Inc. <jblos...@shore.com> wrote: >>> >> >> > Soo...how is this initiative going? How may I help to move it >>> forward? >>> >> >> > >>> >> >> > Best Regards, >>> >> >> > >>> >> >> > John Blossom >>> >> >> > President >>> >> >> > Shore Communications Inc. >>> >> >> > >>> >> >> > where content, technology and people meet. (Salesmark of Shore >>> >> >> > Communications Inc.) >>> >> >> > >>> >> >> > web: shore.com >>> >> >> > blog: contentblogger.com >>> >> >> > email: jblos...@shore.com >>> >> >> > phone: 203.293.8511 >>> >> >> > fax: 203.663.8259 >>> >> >> > twitter: jblossom <https://twitter.com/jblossom> >>> >> >> > google+: google.com/+JohnBlossom >>> >> >> > LinkedIn: John Blossom <http://www.linkedin.com/in/johnblossom> >>> >> >> > facebook: John Blossom >>> >> >> > skype: jblossom >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > On Mon, Jul 8, 2013 at 9:43 AM, John Blossom <jblos...@gmail.com >>> > >>> >> >>wrote: >>> >> >> > >>> >> >> >> Ingenious, Torben, certainly adds efficiency. John >>> >> >> >> >>> >> >> >> On Mon, Jul 1, 2013 at 4:38 AM, Torben Weis < >>> torben.w...@gmail.com> >>> >> >> wrote: >>> >> >> >> >>> >> >> >>> 2013/6/25 Joseph Gentle <jose...@gmail.com> >>> >> >> >>> >>> >> >> >>> > >>> >> >> >>> > >> When peers connect, they send each other missing ops. >>> Figuring >>> >> >>out >>> >> >> >>> > >> which ops are missing can be surprisingly tricky - but >>> we'll >>> >> >> figure >>> >> >> >>> > >> that out later. New ops must be ingested in order, so we >>> always >>> >> >> >>> ingest >>> >> >> >>> > >> an operation after ingesting all of its parents. >>> >> >> >>> > >>> >> >> >>> > Just use a Merkle Tree that is at the same time a prefix >>> tree with >>> >> >> >>> respect >>> >> >> >>> to the hashes of the ops (explanation below). >>> >> >> >>> The bandwidth usage is O(1) if both clients are in sync and >>> O(log >>> >> >>n) if >>> >> >> >>> they have one or few different ops and O(n) in the worst case, >>> >> >>where n >>> >> >> in >>> >> >> >>> the number of ops. >>> >> >> >>> >>> >> >> >>> Constructing the tree is simple. >>> >> >> >>> Let the hash function output 20 bytes and let's encode this in >>> hex. >>> >> >> This >>> >> >> >>> results in a hash-string of 40 hex-characters for each >>> operation. >>> >> >> >>> Each node hashes over the hashes of its children. Leaf-nodes >>> >> >> correspond to >>> >> >> >>> operations and thus use the hash value of their respective >>> >> >>operation. >>> >> >> >>> The tree-invariant is that all siblings on level x share the >>> same >>> >> >> prefix >>> >> >> >>> of >>> >> >> >>> x hex-characters. >>> >> >> >>> The tree is not sent over the network. Instead, clients start >>> >> >>comparing >>> >> >> >>> the >>> >> >> >>> hashes at the root. >>> >> >> >>> >>> >> >> >>> Two clients compare their root hash. If it is equal, the entire >>> >> >>tree is >>> >> >> >>> equal and therefore they are in sync. >>> >> >> >>> If not, they download all direct children and repeat the >>> procedure >>> >> >>for >>> >> >> >>> each >>> >> >> >>> sub-tree rooted by one of these children. >>> >> >> >>> For example, if child number 3 has a different hash, but all >>> others >>> >> >> share >>> >> >> >>> the same hash, then we have learned that there are one or more >>> ops >>> >> >> with a >>> >> >> >>> hash of 3xxxx... that are different and need syncing. >>> >> >> >>> >>> >> >> >>> Typically we can limit the depth of the tree to few levels. 8 >>> levels >>> >> >> >>> already yield a tree that could store 16^8 possible ops. So in >>> the >>> >> >> worst >>> >> >> >>> case two clients need to wait for 8 round-trips to determine a >>> >> >>missing >>> >> >> op. >>> >> >> >>> >>> >> >> >>> In addition, each client sends a time stamp. So when syncing we >>> >> >>report >>> >> >> the >>> >> >> >>> last time stamp received from this client and ask for all ops >>> this >>> >> >> client >>> >> >> >>> received later. If these are few, then simply get them (even >>> if we >>> >> >>know >>> >> >> >>> some of the ops already, because we got them from another >>> client). >>> >> >>If >>> >> >> >>> there >>> >> >> >>> are too many ops, fall back to the merkle tree. With a good >>> >> >> approximation >>> >> >> >>> of RTT and bandwidth, it is easy to calculate which algorithm >>> is the >>> >> >> best >>> >> >> >>> to sync two clients. >>> >> >> >>> >>> >> >> >>> Greetings >>> >> >> >>> Torben >>> >> >> >>> >>> >> >> >> >>> >> >> >> >>> >> >> >>> >> >>> >> >>> >> >>> >> >> >
