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].
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.
