It occurs to me that Wave essentially only supports document-based information, that is all waves and wavelets are designed to hold Google Docs Document-type information. This is fine for majority of the information that will be shared through the Wave protocol; email, instant messaging and basic collaboration are all formatted as such.
However, there are some types of collaborative documents which can't be, at the moment, stored effectively using the Wave protocols - take Spreadsheets for example. In the case of Spreadsheets, you not only want people to be able to collaboratively set and change the cells in the document, but you could also allow people to attach wavelets onto the Spreadsheet cells. One might suggest the use of Wave embeds for anything other that document-based information, however this is a very large barrier to usability. Imagine a Wave document where the only thing inside it was a Wave embed, one that renders and handles spreadsheets on another server. Not only does this provide a barrier to usability on the Wave client (the document-editing toolbars are unnecessary and only invite users to create wavelets outside of the intended document), but essentially reduces Wave to being a container for other collaborative platforms, where the power of Wave is not taken advantage of. I was unable to find an example of what a Wavelet actually looks like in XML form, but I suggest the following additional parameters to Wavelets. I'll explain each of the following parameters below. * documentType="application/spreadsheet" * documentSpecification="<url to document type specification>" * documentFallbackGadgetURL="<url to gadget>" * documentFallbackErrorURL="<url to a webpage>" documentType informs the Wave client of the type of content the Wave contains, whether this be text/html for standard Wave documents, application/spreadsheet for Spreadsheets or application/slides for a Slideshow. The format of the parameter should match that of the internet content types, but it does not necessarily have to use the currently defined MIME types used on the internet (as I can see that some would have no use, such as application/msword). documentTypes should be kept unique, preferably having a set of predefined types established as part of the Wave protocol. However, in case of clashes or unknown document types, the documentSpecification parameter plays an important role. documentSpecification should never be present to the end user, but is instead used to distinguish areas where documentTypes may clash (obviously without the original author of the documentType's intention). More importantly, it allows developers of Wave clients to track the rise of unknown documentTypes and set about implementing support for them into their Wave client as per the specification that was linked to. However, as we want to enable the user to take part collaboratively regardless of whether their Wave client supports it natively, the documentFallbackGadgetURL can be used to specify an embed for the Wave client to use in place of it's own native handling. documentFallbackGadgetURL is not a required parameter for the Wavelet to provide, however the Wavelet must provide either documentFallbackGadgetURL or documentFallbackErrorURL. The documentFallbackGadgetURL points to an gadget which essentially replicates the functionality that a Wave client would implement itself natively. If a Wave client can not display a gadget, it should fallback to documentFallbackErrorURL. documentFallbackErrorURL defines a URL which the Wave client will display along with the appropriate error message. The URL should specify a webpage that instructs the user how they can further participate in the Wave. The following images show how Google Wave might represent a situation where it is unable to render a gadget, and a situation where it is natively rendering a spreadsheet (to highlight the difference between native rendering and how it would currently be displayed in an gadget). Both are direct links. http://www.roket-games.com/weblink/579/no_support.png http://www.roket-games.com/weblink/580/spreadsheet.png So those are my thoughts and ideas on the matter, feedback and suggestions are very much appreciated (obviously the Wave guys would have the final say if they decided to implement this). I'll create a Wave in the wave-disc...@wavesandbox.com to get further feedback there as well. Regards, James. -- You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to google-wave-...@googlegroups.com. To unsubscribe from this group, send email to google-wave-api+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en.
