OK, thanks David, that's clear. Is this functionality currently specified? Did I see the word 'experimental' in another post?
On 4 December 2010 21:52, David Hearnden <[email protected]> wrote: > > In terms of data and protocol, the data associated with these embedded > pages lives in the blip content as key value pairs. > > Just like other doodads, a client would need to have this particular > doodad installed in order for that blip content to be presented as > embedded HTML and JavaScript. Otherwise they just see a grey box with > the doodad name. The content wouldn't be displayed as text, because > it lives inside a custom-tag element in the blip's XML. > > -Dave. > > On Dec 2, 11:56 am, Chris Harvey <[email protected]> wrote: > > What are the implications of inserting "third-party Javascript into a > blip" > > from a federation viewpoint? > > > > I may be missing something in my thinking here but won't the WFP handle > that > > code simply as "blip content" and therefore a second (federated) wave > server > > be a bit confused when it sees that code (and thence simply display it as > > "plain text")? > > > > -- > > 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. > > -- 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.
