I haven't heard about subwavelets before. Is it in the whitepapers? On Wed, Feb 23, 2011 at 00:21, Paul Thomas <[email protected]> wrote:
> The simplest would just be to have subwavelts. In that they are two > wavelets > with distinct histories, but one is in the other. But regardless their > histories > are only interweaved after merging. If you are copying over, then > esscailly > that is a snapshot with no history. subwavelts they are distinct entities. > The > exist both separately and with one embedded in another. > > > > > ----- Original Message ---- > From: Sean Wendt <[email protected]> > To: [email protected] > Sent: Tue, 22 February, 2011 22:55:35 > Subject: Re: is wave playback a priority right now? > > I was contemplating the things said in the "What is Google Wave?" video > about the monster: email is bad because of the fragmentation of a > conversation thread, so wave unifies the history and you can invite > everyone > and it is good. > > But what if you wanted to apply the same improvement to wave itself and > merge two waves? > Is crossposting currently the only option? > If we made merging possible, would the result have a history-'tree' with > its root in then present? Otherwise, how would the histories be weaved > together? How would the separate contents of the two waves appear after > merging? > Or should merging be done using linking, with a blip as a mountpoint > inside the wave, which you can then also use to mount userspace filesystems > from your computer, on the moon, sitting on a pile of pizza, made of > kryptonite. Ignore that last part. > > On Tue, Feb 22, 2011 at 16:41, Juan Antonio Osorio <[email protected] > >wrote: > > > Hi all, > > > > We currently need the playback because we are developing a wave-based > > application with educational purposes. This application is part of a > > research > > involving "context intelligence", which, in this particular case, is how > > students > > interact in a collaborative environment such as the Wave Client. In this > > application, playback is a key feature, because it gives researchers the > > possibility of looking at the student's progress throughout various > tests, > > thus > > being a very important source of information. > > > > Students will be solving "Database modelling"-like problems, and creating > > ER Diagrams (using a Gadget that was previously programmed for GWave). > > > > What I was thinking for the playback, was using the WaveletContainer > that's > > stored locally, and applying the Deltas (that where stored in the > > DeltaStoreBasedWaveletState) to a temporary Document that would be > > created exclusively for playback purposes. > > > > We're still not sure how to implement this but hopefully, we'll get a > > clearer > > perspective of the code within these weeks. Thanks for the ideas, and any > > more suggestions are more than welcome. > > > > On Tue, Feb 22, 2011 at 8:22 AM, Thomas Wrobel <[email protected]> > > wrote: > > > > > Speaking as a gwave user, the most useful aspect of playback was when > > > something went wrong, accidental deletion or copying over of content. > > > (usually with a crash too if the wave was big...) > > > Being able to revert to a previous version via the playback was the > > > easiest way to solve the problem. > > > > > > Speaking as someone working on a Augmented Reality use case for > > > wfp...essentially not dealing with text at all, but 3d models placed > > > and positioned with data stored in blips. The idea of playing back the > > > whole creation of a 3d scene is very appealing. (especially if the > > > scene was made by a large group collaboration). > > > > > > So those are the two use's in my mind and while I have no real > > > knowledge of the inner workings of the wave client or server beyond an > > > overview of the protocol, it seems having "key frames" might be the > > > best compromise solution between storage and loading speed. > > > > > > -Thomas > > > arwave.org > > > > > > ~~~~~~ > > > Reviews of anything, by anyone; > > > www.rateoholic.co.uk > > > Please try out my new site and give feedback :) > > > > > > > > > > > > On 22 February 2011 15:06, Paul Thomas <[email protected]> wrote: > > > > Thanks is interesting. > > > > > > > > One point of playback is to quickly get updated on what you have > > missed. > > > So > > > > therefore you don't really have to have have every singe change. > > > > > > > > It is kind of like flicking through the unread blips, except that > > doesn't > > > have > > > > blip level history. I would be good if you could flick through unread > > > changes. > > > > > > > > Using history to revert or fork wave might be used less often so that > > > sort of > > > > history doesn't need to be played back smoothly, it just needs to be > > > usable. > > > > > > > > > > > > > > > > > > > > ----- Original Message ---- > > > > From: David Hearnden <[email protected]> > > > > To: [email protected] > > > > Sent: Tue, 22 February, 2011 12:43:23 > > > > Subject: Re: is wave playback a priority right now? > > > > > > > > Hi Gerardo, > > > > > > > > It depends on what kind of playback experience you would like. > > > > > > > > In Google Wave, playback does not necessarily play things > > > chronologically, > > > > but instead can reorder things to make the history simpler. e.g., if > > two > > > > users A and B are concurrently adding their own replies, then the > > > playback > > > > history can show A's complete reply as one history frame, then B's > > reply > > > in > > > > a subsequent frame, even though there was no point in chronological > > > history > > > > where A's reply was complete and B hadn't started replying ...if > that > > > makes > > > > sense. So mild reordering of the operation history in order to make > it > > > > simpler is one complex part of playback. > > > > > > > > Another part of playback is grouping segments of history into > "frames", > > > > where the boundaries between frames are historically interesting > events > > > > (starting editing, stopping editing, participants being added and > > > removed, > > > > etc). Finding a good set of rules to group operations into useful > > frames > > > is > > > > another complex part of playback. > > > > > > > > Being able to step backwards as well as forwards adds more > complexity, > > > > because of the difference between "reversible" and "invertible" ops > > (the > > > > inverse of an invertible op is derivable from the op itself; the > > inverse > > > of > > > > a reversible op, however, depends on the state to which it is > applied). > > > > > > > > There are many other cases where adding some improvement to the > feature > > > can > > > > add significant complexity, e.g., efficiently moving wave state > between > > > two > > > > frames points in history, rather than applying all the operations one > > by > > > > one. > > > > > > > > So starting out with a simple goal of just playing back the > operations > > > > individually, in order to play forwards through history, would be a > > good > > > > start. Perhaps adding in some simple framing (no re-ordering) to > group > > > ops > > > > based on timestamp so that chunks of edits appear as a single frame? > I > > > > think that would be the start of a reasonably usable playback > feature. > > > The > > > > web client can create a wave model on an empty state, stub out the > > > incoming > > > > operation stream component (MuxConnector) with a new one that's > hooked > > up > > > > some play/pause UI control, and fetch the entire operation history > from > > > the > > > > server, putting those ops in the operation stream based on that UI > > > control. > > > > It will be probably be quite slow, and won't scale for waves with big > > > > history, but it's certinaly a great start. > > > > > > > > Beyond that, you'd probably want to have a separate endpoint (maybe > > even > > > a > > > > separate protocol, rather than the client/server operation protocol) > > for > > > > delivering a more compact representation of the history to the > client. > > > > e.g., do some basic framing, and compose the ops in each frame > together > > > to > > > > only a few ops per frame. That will significantly reduce the > > client-side > > > > processing, and sounds reasonably doable right now. > > > > > > > > -Dave > > > > > > > > On Tue, Feb 22, 2011 at 6:31 AM, Gerardo Lozano <[email protected] > > > > > wrote: > > > > > > > >> What would be the best way to approach playback implementation? > > > >> > > > >> This is what we've got: > > > >> > > > >> We've been looking at the code for the past few days now, and we > think > > > that > > > >> a good approach is to somehow get the a history of the wavelet > deltas > > > >> (either from memory of from store) and then either apply the delta > > (done > > > >> with or in an Instance WaveletState) or append (done with or in an > > > instance > > > >> of WaveletProvider them each time the playback is requested. > > > >> > > > >> To us, it seems that the most viable way to implement playback is to > > get > > > >> the > > > >> delta history from the store (with last week's implementation) and > > then > > > >> somehow build up from that. > > > >> > > > >> What would you guys recommend doing? > > > >> > > > >> > > > >> > > > >> 2011/2/8 James Purser <[email protected]> > > > >> > > > >> > Not at the moment, but if anyone wants to pick it up and run with > > it, > > > >> then > > > >> > please feel free :) > > > >> > > > > >> > James > > > >> > > > > >> > On Wed, Feb 9, 2011 at 5:17 AM, Yuri Z <[email protected]> wrote: > > > >> > > > > >> > > AFAIK - playback is not a priority at the moment and no one is > > > working > > > >> on > > > >> > > it. If someone does - please correct me. > > > >> > > > > > >> > > 2011/2/8 Gerardo Lozano <[email protected]> > > > >> > > > > > >> > > > Hi everybody! > > > >> > > > > > > >> > > > Is anybody planning on working on wave playback? This is on > the > > > WIAB > > > >> > > > roadmap, but it has a blank status. > > > >> > > > > > > >> > > > Thanks! > > > >> > > > > > > >> > > > -- > > > >> > > > > > > >> > > > Gerardo L. > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> > > > >> Gerardo L. > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Juan Antonio Osorio R. > > e-mail: [email protected] > > > > "All truly great thoughts are conceived by walking." > > - F.N. > > > > > > >
