Michael, Thank you very much for engaging this topic.
Your observations highlighted some of the key challenges and concerns that I have factored into the presentation deck that I shared earlier: https://docs.google.com/presentation/d/1pNsrX26947QH89Ot3k62nlKKSRFLmVgBWxcIEne8VYI/edit?usp=sharing Making the OT core engine a stand-alone service with associated APIs and apps development toolkits that multiple UI apps and applets could hook into is definitely one of my objectives for Wave. The other objective is to be able to store waves as data objects independent of a given vendor's infrastructure. Google Drive Realtime API is interesting and something that Wave should probably interface with via adapters, but I think that it presents an opportunity to provide the OT-driven conversational data models in a contrasting and highly appealing alternative. Data typing is a critical component to getting this "right", however it's done it needs to allow apps to provide an array of different services within the Wave data model (text, rich text, data tables, "X"). My main concern with data typing is that it be done in a way that allows lots of applications to use OT services, but also which enable other apps to use the data that they store in waves - in other words to allow but to discourage proprietary data formats. I'd be interested in sponsoring a hangout private to Apache Wave committers to discuss these sorts of key topics. These are some of the core architecture questions that need to be agreed upon sooner rather than later. I see enormous potential for Wave technologies if we can package them in a way that would allow multiple UIs applications to access common waves that are easily federated/transported/migrated to any host running Wave services. Agreed that some teams with architectural focus would be beneficial, especially as the "teasing apart" of Wave from a monolithic application to a more modular set of services seems to be the overall direction of development. Looking forward to further comments from you and others on this thread. On Sun, Jun 16, 2013 at 4:29 AM, Michael MacFadden < michael.macfad...@gmail.com> wrote: > All, > > What we would need to do to support integration with Open Office, or any > other app, is abstract our OT Core Engine in two ways. First it would > need to become a stand alone service that other apps could hook in to. > Second we would need to change the operations to be more generic than the > current set that are tied to the wave conversation model. The current OT > model is not flexible enough to become a core OT framework for other apps > to use. > > One of the things that always struck me in Wave was that the conversation > model used OT but that the gadget API did not. This is in part because > gadgets had their own data model which had nothing to do with > conversations (lines, annotations, etc) which were not supported well by > Wave's OT. > > The google real time API is a step in that direction, but there are a > couple problems with it. 1) It is a javascript API rather than a service. > 2) You are forced to use it's data types rather than your own, and 3) your > data must be stored on Drive. > > I have seen two proprietary OT engines that seem to work well acting as a > service and one open source one. If we are to grow, I think this is the > direction the OT code needs to go in. > > I think Joseph and I (so far as I can tell) are probably the two most > interested people in doing this. > > I think we need to develop mini communities within wave. Those that are > focused on the OT / CC Stack, those that are focused on clients, those > that are interested in federation, etc. If we can pair up some folks that > are interested in each of these areas (and others), I think we can make > some progress. > > ~Michael > > On 6/15/13 8:25 PM, "Yuri Z" <vega...@gmail.com> wrote: > > >Just a note - the rendering to static HTML is experimental and wasn't > >actually submitted to official Apache Wave repo since there was no > >agreement on the way on how this should implemented right without breaking > >static bindings when compiling from GWT to Javascript. > > > > > >On Sat, Jun 15, 2013 at 10:05 PM, Zachary ³Gamer_Z.² Yaro > ><zmy...@gmail.com>wrote: > > > >> @Fleeky, Yuri actually added some > >> code< > >> > >> > https://github.com/vega113/WaveInCloud/tree/master/src/org/waveprotocol/b > >>ox/server/rpc/render > >> >to > >> WIAB for static HTML rendering, so that could be a solution to your > >> publishing problems. In addition, Google Wave, Rizzoma, and (I* *think) > >> WIAB (with Yuri's code) support exporting to HTML or PDF. Is that what > >>you > >> were asking for? > >> > >> @John, I definitely like the idea of being able to log into a wave > >>server > >> from OpenOffice and edit waves through it, but I think we need a > >> standardized wave client-server protocol first. > >> > >> > >> ‹Zachary ³Gamer_Z.² Yaro > >> > >> > >> On 15 June 2013 12:34, Fleeky Flanco <fle...@gmail.com> wrote: > >> > >> > john, i was infact using wave as a google docs replacement for a > >>while it > >> > worked pretty good the only problem i had with it was that i couldnt > >> > 'publish' static updates to a front facing page to share with people > >>who > >> > didnt feel like registering on my wave server. > >> > > >> > an openoffice for wave would be extremely usefull, and could have an > >> > extremely large impact imo. wave is also already very very close to > >> having > >> > this funcitonality. etherpad lite sortof already does this, but i kept > >> > going back to wave because it was actually more responsive, > >>featurefull, > >> > and actually crashed less. > >> > > >> > > >> > > >> > > >> > On Sat, Jun 15, 2013 at 9:29 AM, John Blossom <jblos...@gmail.com> > >> wrote: > >> > > >> > > I had the down-the-road thought just now that I wanted to put into > >> > > circulation before I forgot about it. > >> > > > >> > > One of the challenges that we will face in developing open source > >>Wave > >> is > >> > > that Google and others - but mostly Google - are out there using > >> > > operational transform technologies also. So far the Google Drive > >> Realtime > >> > > API hasn't had much impact, but it's being "demoed" successfully in > >> Drive > >> > > apps like Docs and Presentations. > >> > > > >> > > The advantages of an open source Wave implementation are, of course, > >> that > >> > > people can own their own data and identity management without > >>having to > >> > > rely on a specific vendor's infrastructure. But the flip side of > >>that > >> is > >> > > that you have to look carefully at infrastructure that integrates OT > >> and > >> > > understand what you have to do similarly to showcase your > >>technologies. > >> > > > >> > > That brings me to OpenOffice. At some point it will be beneficial to > >> > > consider how the Wave API can enable apps in the OpenOffice suite to > >> take > >> > > advantage of OT technologies in Wave and its other various > >>features. In > >> > > fact, it's not unthinkable that an OpenOffice for Wave variant might > >> not > >> > be > >> > > feasible at some point, maintaining a familiar office automation > >> paradigm > >> > > as a user interface for those who relate to that sort of tool but > >> having > >> > > the power of Wave to drive collaborative document editing, comments, > >> > > embedded apps and so on, with Wave data structures underneath the OO > >> > > interface. > >> > > > >> > > Just idle thoughts for now, but if we make good progress over the > >>next > >> > > several months, it's a sub-project that may help to attract more > >> > developers > >> > > to Wave technologies. > >> > > > >> > > All the best, > >> > > > >> > > John Blossom > >> > > > >> > > >> > > >
