Subwavlets are just wavelets, except they are "embedded" within another wavelet. Like in google wave when you want to send a private message within the context of a wave. You could do that with any recipients.
----- Original Message ---- From: Thomas Wrobel <[email protected]> To: [email protected] Cc: Sean Wendt <[email protected]> Sent: Wed, 23 February, 2011 20:30:51 Subject: Re: is wave playback a priority right now? Would a subwavelet just be, metaphorically, akin to an iFrame? I could see that being pretty usefull, but also potentialy pretty complex. I mean, would all the members of the overall wave have to also be invited to the subwave to see it? -Thomas arwave.org ~~~~~~ Reviews of anything, by anyone; www.rateoholic.co.uk Please try out my new site and give feedback :) On 23 February 2011 21:00, Sean Wendt <[email protected]> wrote: > 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. >> > >> >> >> >> >> >
