Thanks Alex, I'm looking forward to persistence and having a look at a raw wave document. Also the ability to cycle through the histories - this was one of waves best features.
My remaining questions relate to the robot API, which as I understand it is already implemented in WIAB. How would I go about adding the example echoey robot to a local wave? Cheers, Daniel On 20 nov., 04:08, Alex North <[email protected]> wrote: > Hi Daniel, > > Thanks for your interest! I have some answers below but please let me know > if you'd like more detail on particular areas. > > On 19 November 2010 14:13, DanielS <[email protected]> wrote: > > > > > > > > > > > Hi all, > > > I'm trying to get a grips with what all the code does, and am hoping > > you guys can help simplify things (time is a big constraint at the > > moment). I apologize if they are stupid questions, my understanding of > > WIAB is very superficial at the moment and I'm finding the already > > large code base quite intimidating. > > > My main questions are: > > > 1) Wave persistence - what's the main problem here and why hasn't it > > been implemented? My current understanding is that a wave is basically > > an xml document. What object contains all the information for the wave > > and what is the challenge in saving that to a file? > > * I see now that the title of the waves are saved but you get an error > > when trying to open it... > > "XML" document is far too much of a simplification. The persisted state of a > wave includes it's entire history, comprising the operations that got it > into its current state. > > Persistence is non-trivial because the server must make guarantees about the > consistency of the data. A server typically needs to persist more useful > forms of the data than just the delta history (e.g. the current snapshot) > and ensuring those representations stay in sync is again not trivial. > > It's coming along though, mostly implemented. > > > > > 2) A lot of the work seems to be on getting federation working... Is > > most of the federation code kept separate? What would WIAB look like > > without federation (a stripped down version)? > > WIAB works just fine without federation. We could probably do more to > separate out the federation code but if you don't want to federate, the > potential of federation shouldn't hold you back. > > 3) Is there a detailed object diagram going around, with the real > > > class names and how they are all related? Maybe there is an eclipse > > plugin or something I don't know about to generate this... > > No, sorry. The codebase is just too complex, and too rapidly changing, for > anyone to have attempted something like that. But the talks from our recent > summit might help you get an idea of what's going on: > > http://www.youtube.com/results?search_query=wavesummit&search=tag > > In particular, if you'll excuse me nominating some of my own talks, WIAB > Architecture <http://www.youtube.com/watch?v=pDPBnmRDkag>, Wave > Model<http://www.youtube.com/watch?v=6ZqpeFydq4A>, > and Wave Server <http://www.youtube.com/watch?v=7dbDhmX2v6E>. > > Hope that helps, > Alex > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/wave-protocol?hl=en. -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
