John, Again I don't mean to delay the effort. But looking at the attendee responses, I only see one person on the list that has agreed to attend that has really been heavily working OT issues in the last year or so (Joseph). So I am not sure what the objectives or the outcome of the meeting will be with such low participation from OT experts.
By no means do I mean to diminish any one else's capabilities, but if the intention is to really dig in to OT, then I think we night need additional participation to be successful. ~Michael On Jul 23, 2013, at 8:40 AM, "John Blossom - Shore Communications Inc." <jblos...@shore.com> wrote: > I agree wholeheartedly that the entire Apache Wave community should be > excited about participating, and I assume that everyone on the list is > seeing this and should want to join in. If we have to reschedule, no > biggie, we're at square zero and it's more about getting people on board > and brainstorming. If you've been invited already, then invite others who > you think should be excited. To that end, here's the link to the event: > > https://plus.google.com/u/0/+JohnBlossom/posts/KTB6EkxB99q > > If you're an Apache Wave committer and you miss the event, then you'll be > able to view it via YouTube via a link that I'll post here. > > I do want to start accelerating communications more in the community, but > this is a busy week. > > > 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 Tue, Jul 23, 2013 at 10:16 AM, Michael MacFadden < > michael.macfad...@gmail.com> wrote: > >> I don't want to delay this thing, but are there really no other people who >> are interested in this? I think we should really try to reach out >> personally to some other folks to see if we can attract them in. >> >> ~Michael >> >> On 7/23/13 7:00 AM, "John Blossom" <jblos...@gmail.com> wrote: >> >>> 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 >> >> >>
