Hi all, This issue has also been occupying our thoughts. We certainly don't have all the answers yet but let me relay some of what we're thinking about.
Firstly, yes Google Wave currently only supports document-based information. That is, the ops define a the state of structured XML-like document. However, the interpretation of that document is not fundamentally limited. One could represent a spreadsheet or presentation in a wave document. We haven't tried yet, but with an appropriate representation you would indeed have a spreadsheet/presentation that is concurrently editable, etc, for "free". However, clients need to know how to interpret (and in the case of web clients, render) those interpretations of a document. This we haven't worked out well yet. I think at least part of the story will come from schemas (see the thread I recently posted in). A schema defines the syntax of a document so this can be used to choose an appropriate rendering, if the schema is recognised. What to do when the schema is not recognised is an even trickier problem. A gadget to interpret it is a good idea, but gadgets, at least currently, have a restricted ability to edit concurrently; you can't both edit the same gadget field at the same time and have clean concurrency resolution. Fetching code to run in the client sounds attractive (and we're exploring it) but opens up a host of security issues. I'm glad to hear some people are already storing different types of data in waves. The Google Wave system uses waves for many different types of data, two simple examples being extension installation settings and your profile information. We plan to release some more code and documentation soon explaining how we do it. I share Chris's hope that the community process will help us all work out how to extend wave specs to allow for a rapid expansion in the types of information you can store in a wave. Cheers, Alex On 25 February 2010 16:12, Christopher Harvey <[email protected]> wrote: > James, > > You highlight an issue that has also been causing me thought: given that > wave servers will proliferate (along with their associated clients), how > will a client handle displaying a wavelet that it does not understand? > > As you point out, the current specs/papers focus on the conversational > document. A wavelet is only specified to deal with "conversation manifest > documents and blip documents". > > However, does the wavelet itself not already contain the namespace ('b' - > blip, or 'conversation' - conversation manifest), and, thus, is the client > not already in a position to handle (or not, as the case may be) a wavelet > that does not contain a namespace known to that client? > > We are already implementing a wide-range of business documents (invoices, > quotes, orders, ...) directly within the Wave framework. To do this, we have > had to 'extend' the spec by creating a new namespace ('d' - business > document). So, within any wave we can have many wavelets, some blip-based > conversations, some business documents. > > Now, what would happen if I federated to, say, a Google server/client, > which then requested a wave that contained *both* types of wavelets? > > I assume, at present, the Google client would either ignore the wavelets > with a 'd' namespace, or handle them unpredictably. > > The evolving-community-process will, in one form or another, (eventually) > take care of extending Wave Protocol specs to include extensions that go > beyond the flexibility provided by robot/gadgets. > > So, I'm not sure that it is necessary to explicitly specify within the > wavelet what type it is but the idea of specifying a fall-back mechanism > (gadgets and/or URLs) sounds *essential* to me. At least all clients could > gracefully handle wavelets that they do not understand. > > Having said that, I am not sure where, in the federation spec, the > namespaces are actually used within a wavelet; I assume they are embedded > within the wavelet document (CDATA). > > In addition, there is the much bigger question of how docops are managed > (for, say, a spreadsheet or business document) within the > currently-specified design. This is an area we are presently 'exploring'. > It's certainly fun. > > Regards > Chris > -- > iotawave.org > Singapore > > -- > 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%[email protected]> > . > 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.
