On Thu, Jun 13, 2013 at 9:05 AM, Patrick Coleman <patcole...@google.com> wrote: > Fascinating thread, it's been great to follow the huge increase in interest > of late :)
Nice to see you Pat! How're things? > One question that I'm hoping might get answered before people rewrite > anything: > is there a plan for keeping the OT implementations of federated > clients/servers in sync? > > It's a requirement both for federation to servers not running WiaB, plus > client/server split for clients not using WiaB code, though I don't think > it's been answered. > GWT was GWave's solution to that; allowing a java server, plus java > (robots/android) and JS (web) clients, and can now even do iOS given J2objc Its a really good point. I ported a couple of my OT type implementations from JS to pure C and I had exactly this problem. I found the easiest way to test the C code was to use my javascript randomizer (which I had anyway). I generated a few hundred megs of ops (saved as JSON) along with the result of transforming / composing / etc. Then I parsed the JSON back into C ops, transformed in C and made sure the results matched. That was easier than porting the randomizer itself to C, and it made sure that the two implementations were compatible. The other thing going forward is how we'll deal with protocol version & operation version migration issues. But I guess thats just going to be some details to work through. > Alternatives are possible (e.g. standards & suite of acceptance tests, or > generators based on a language-neutral spec, or ....) > but would require a good justification to move away from having a GWT > library as the single source of truth in implementation. I actually found that porting my core transform / etc functions from JS to C was surprisingly easy. I'm much more concerned about the wave editor. You can write automated tests for OT. Here's the same OT apply function in C and JS: https://github.com/share/libot/blob/master/text.c#L493-L569 https://github.com/share/ottypes/blob/master/lib/text.js#L187-L217 This sort of porting work certainly takes time, but its super easy compared to writing the code in the first place. > Note that that discussion (ot implementation) should be separate from UI > layout / interaction language, but the latter seems much more flexible in > terms of solutions. > > (and to join in John's target-making: Joseph, did you try 'GWT' in that > search rather than 'google web toolkit'? :) Oooh there's a lot more of that by volume, though its still in decline (though so are both java and javascript). Try comparing to jquery. (I know some people use jquery with gwt, but I bet its a tiny % of jquery's total users). -J
