Leading up to extending the Google Wave preview beyond developers (on
September 30th), we wanted to provide some more specific guidance
about the things we're working on with the Google Wave APIs. We're
working hard to balance stability and reliability of the system with
adding new API features and fixing the existing bugs.
As a brief review, here are some recent things we've done related to
the APIs:
* Improved the extension manifest file
* Made it easy to create extension installers (the "puzzle piece"
wave). From the debug menu, simply select "Add Extension Installer"
* Open sourced the Java Robots API
* Implemented Context for robots
* Added a hover menu to gadgets
* Append content to document with simple HTML
* Initial robot to gadget communication (though it still needs some
work!)
We're excited by the early developments we've seen thus far, and look
forward to getting more feedback on the existing APIs and the roadmap
below.
- - -
Douwe
Google Wave API Tech Lead
*Extensions*
Design good flow for adding extensions, which includes:
- Enabling users to easily discover extension installers
- Browsing experience for insert gadgets and robots from a gallery
- Enabling user management of their installed extensions (& easily de-
install)
- Stretch goal: Expand the extension system with more hooks and
actions.
The goal, in the short term, is to make it easier for a given
extension to hook into conversations without being actively added to
wave. For example, right now you can insert a YouTube gadget from a
link to a YouTube video. We'll open it up to let an extension trigger
on a regular expression over any link, so you can build all types of
"previewers." This mechanism will not just trigger for link
annotations, but for any annotation.
Robots
- New Robots wire protocol (v0.2)
Shortly we will publish the proposed next version of the robots wire
protocol. We'd love to get your feedback prior to implementing it.
- Java and Python API parity
Getting the two APIs to have feature parity
- Robot Gateway / OpenSocial RPC Access
Robots only react to events right now. By allowing the robots to
authenticate themselves through the OpenSocial RPC protocol, robots
can create and retrieve waves without being triggered by the wave
system first, which will allow for more "active" robots.
- Better multiple wave access
Right now it is hard to create robots that keep multiple waves in
sync. We'll add support to updates waves "blindly" (i.e. without
knowing for sure what their current context is) in a less dangerous
way by allowing to update annotated ranges in another wave and further
more make it possible to bring waves outside of the current context
into context.
- Sunset the existing robots cron mechanism
After we open the Robot Gateway, the basic wave cron system will no
longer be needed since robots could use Google App Engine's native
cron system or the Google App Engine Task Queue API.
- Gateway support
Improve the current tweety type of access to support outside
addresses of the form address+ro...@appspot.com. These addresses will
come with their own profiles and will make it possible to better
support actions on behalf of external entities.
Gadgets
- Full OpenSocial gadget support
While we already support the underlying gadget XML and related
features, we will add full support for the OpenSocial JavaScript
library (i.e. feature requires="opensocial-0.9")
This includes a mapping of the OpenSocial concepts onto the wave
concepts and supporting the actual OpenSocial APIs as well as
gadgets.io.makeRequest.
- DiffOnOpen/Playback state mode for gadgets
Gagdets currently automatically support playback, but sometimes you
want to be able to do something explicitly (e.g. in a chess game show
the previous place of a piece). The same goes for diff-on-open.
Currently gadgets only show the current state - with diff-on-open
support they will be able to show the user what has changed since last
time.
- Google Web Toolkit (GWT) gadgets
For complex gadgets, GWT is a rather nice way to develop. We'll
provide a library to build gadgets inside of GWT and a small framework
to run the same code outside of wave to make debugging with an actual
debugger possible.
Embed
- Expanded UI configuration:
Switches to display toolbar, participant list, bottom tools.
- Methods to switch the wave in and out of edit mode
- Stretch goal: Read-only anonymous access so people don't have to be
logged into Google Wave to see embedded waves.
Future Thoughts
Following September 30th, we have several things in mind, but it'll be
important to see what gets built in the meantime and hear your
feedback on the APIs as things evolve.
Some ideas we're currently thinking about for later in the year:
- Expand the number of hooks extensions can plug into (via regular
expressions)
- Enable robots that aren't required to use Google App Engine
- Provide an API for robots to access attachments, search and contact
- Explore tools for improving the robot development/debug experience
- Expand the embedding API to cover more use cases
> Leading up to extending the Google Wave preview beyond developers (on
> September 30th), we wanted to provide some more specific guidance
> about the things we're working on with the Google Wave APIs. We're
> working hard to balance stability and reliability of the system with
> adding new API features and fixing the existing bugs.
> As a brief review, here are some recent things we've done related to
> the APIs:
> * Improved the extension manifest file
> * Made it easy to create extension installers (the "puzzle piece"
> wave). From the debug menu, simply select "Add Extension Installer"
> * Open sourced the Java Robots API
> * Implemented Context for robots
> * Added a hover menu to gadgets
> * Append content to document with simple HTML
> * Initial robot to gadget communication (though it still needs some
> work!)
> We're excited by the early developments we've seen thus far, and look
> forward to getting more feedback on the existing APIs and the roadmap
> below.
> - - -
> Douwe
> Google Wave API Tech Lead
> *Extensions*
> Design good flow for adding extensions, which includes:
> - Enabling users to easily discover extension installers
> - Browsing experience for insert gadgets and robots from a gallery
> - Enabling user management of their installed extensions (& easily de-
> install)
> - Stretch goal: Expand the extension system with more hooks and
> actions.
> The goal, in the short term, is to make it easier for a given
> extension to hook into conversations without being actively added to
> wave. For example, right now you can insert a YouTube gadget from a
> link to a YouTube video. We'll open it up to let an extension trigger
> on a regular expression over any link, so you can build all types of
> "previewers." This mechanism will not just trigger for link
> annotations, but for any annotation.
> Robots
> - New Robots wire protocol (v0.2)
> Shortly we will publish the proposed next version of the robots wire
> protocol. We'd love to get your feedback prior to implementing it.
> - Java and Python API parity
> Getting the two APIs to have feature parity
> - Robot Gateway / OpenSocial RPC Access
> Robots only react to events right now. By allowing the robots to
> authenticate themselves through the OpenSocial RPC protocol, robots
> can create and retrieve waves without being triggered by the wave
> system first, which will allow for more "active" robots.
> - Better multiple wave access
> Right now it is hard to create robots that keep multiple waves in
> sync. We'll add support to updates waves "blindly" (i.e. without
> knowing for sure what their current context is) in a less dangerous
> way by allowing to update annotated ranges in another wave and further
> more make it possible to bring waves outside of the current context
> into context.
> - Sunset the existing robots cron mechanism
> After we open the Robot Gateway, the basic wave cron system will no
> longer be needed since robots could use Google App Engine's native
> cron system or the Google App Engine Task Queue API.
> - Gateway support
> Improve the current tweety type of access to support outside
> addresses of the form address+ro...@appspot.com<address%2Bro...@appspot.com>.
> These addresses will
> come with their own profiles and will make it possible to better
> support actions on behalf of external entities.
> Gadgets
> - Full OpenSocial gadget support
> While we already support the underlying gadget XML and related
> features, we will add full support for the OpenSocial JavaScript
> library (i.e. feature requires="opensocial-0.9")
> This includes a mapping of the OpenSocial concepts onto the wave
> concepts and supporting the actual OpenSocial APIs as well as
> gadgets.io.makeRequest.
> - DiffOnOpen/Playback state mode for gadgets
> Gagdets currently automatically support playback, but sometimes you
> want to be able to do something explicitly (e.g. in a chess game show
> the previous place of a piece). The same goes for diff-on-open.
> Currently gadgets only show the current state - with diff-on-open
> support they will be able to show the user what has changed since last
> time.
> - Google Web Toolkit (GWT) gadgets
> For complex gadgets, GWT is a rather nice way to develop. We'll
> provide a library to build gadgets inside of GWT and a small framework
> to run the same code outside of wave to make debugging with an actual
> debugger possible.
> Embed
> - Expanded UI configuration:
> Switches to display toolbar, participant list, bottom tools.
> - Methods to switch the wave in and out of edit mode
> - Stretch goal: Read-only anonymous access so people don't have to be
> logged into Google Wave to see embedded waves.
> Future Thoughts
> Following September 30th, we have several things in mind, but it'll be
> important to see what gets built in the meantime and hear your
> feedback on the APIs as things evolve.
> Some ideas we're currently thinking about for later in the year:
> - Expand the number of hooks extensions can plug into (via regular
> expressions)
> - Enable robots that aren't required to use Google App Engine
> - Provide an API for robots to access attachments, search and contact
> - Explore tools for improving the robot development/debug experience
> - Expand the embedding API to cover more use cases
(google)<douwe.osi...@gmail.com> wrote: > Embed > - Stretch goal: Read-only anonymous access so people don't have to be > logged into Google Wave to see embedded waves.
I sure hope you have the flexibility to make this particular stretch goal this fall.
This would be a critical one for the email bridge, PoppyWave. With this, we can provide a link back to the full wave for external participants in addition to the textual updates we push to them and get back from them. This will greatly extend the reach of your 100K public launch this fall.
I've already reported this as an enhancement request:
Thanks for the update, Douwe. Looks quite promising and addresses
many of the limitations in the current API. A few other items for
consideration:
- Enable robots to obtain a permanent wave/wavelet/blip ID upon
creation, rather than the complicated callback mechanism required
today
- Publically immutable regions in a wave/wavelet/blip. I have
encountered use cases where a robot needs to maintain in-wave state
that also requires specific positioning in a blip and/or total control
of a blip. "Non-visual" state can currently be managed using data
documents or back-end persistence, but it would be ideal to be able to
have robots (and people) create blips and wavelets that can only be
modified by themselves
- HTML "islands" in TextView elements (it sounds like you're
considering a first version of this in the Sept 30th release)
- Intra-wave hyperlinking (e.g. anchors within a wave that can be used
for navigation inside a single wave)
- Structured templates for waves to provide for specific layout/
styling scenarios that could allow waves to visually and structurally
emulate well-known collaborative document models such as Wikis,
discussion groups, microblogs/blogs, etc...this might include styling
based on "level"/depth of the wavelet/blip, limitations on where/how
to reply or append content, which content to display in blips
- The ability to display "inline history" in waves. The "who, what
and when" of blip submittals is captured, so it would be nice to
enable this to be displayed in the wave based on styling/preferences.
This would tie in nicely with the item above.
- It would be useful to provide something analogous to "mime types" or
"document types" to enable semantic understanding of a wave's content
in certain use cases. While this could be accomplished with tags,
there should be a higher level, more structured approach
Just a few thoughts, hope you find them useful.
Rick
On Aug 12, 1:04 am, "Douwe Osinga (google)" <douwe.osi...@gmail.com>
wrote:
> Leading up to extending the Google Wave preview beyond developers (on
> September 30th), we wanted to provide some more specific guidance
> about the things we're working on with the Google Wave APIs. We're
> working hard to balance stability and reliability of the system with
> adding new API features and fixing the existing bugs.
> As a brief review, here are some recent things we've done related to
> the APIs:
> * Improved the extension manifest file
> * Made it easy to create extension installers (the "puzzle piece"
> wave). From the debug menu, simply select "Add Extension Installer"
> * Open sourced the Java Robots API
> * Implemented Context for robots
> * Added a hover menu to gadgets
> * Append content to document with simple HTML
> * Initial robot to gadget communication (though it still needs some
> work!)
> We're excited by the early developments we've seen thus far, and look
> forward to getting more feedback on the existing APIs and the roadmap
> below.
> - - -
> Douwe
> Google Wave API Tech Lead
> *Extensions*
> Design good flow for adding extensions, which includes:
> - Enabling users to easily discover extension installers
> - Browsing experience for insert gadgets and robots from a gallery
> - Enabling user management of their installed extensions (& easily de-
> install)
> - Stretch goal: Expand the extension system with more hooks and
> actions.
> The goal, in the short term, is to make it easier for a given
> extension to hook into conversations without being actively added to
> wave. For example, right now you can insert a YouTube gadget from a
> link to a YouTube video. We'll open it up to let an extension trigger
> on a regular expression over any link, so you can build all types of
> "previewers." This mechanism will not just trigger for link
> annotations, but for any annotation.
> Robots
> - New Robots wire protocol (v0.2)
> Shortly we will publish the proposed next version of the robots wire
> protocol. We'd love to get your feedback prior to implementing it.
> - Java and Python API parity
> Getting the two APIs to have feature parity
> - Robot Gateway / OpenSocial RPC Access
> Robots only react to events right now. By allowing the robots to
> authenticate themselves through the OpenSocial RPC protocol, robots
> can create and retrieve waves without being triggered by the wave
> system first, which will allow for more "active" robots.
> - Better multiple wave access
> Right now it is hard to create robots that keep multiple waves in
> sync. We'll add support to updates waves "blindly" (i.e. without
> knowing for sure what their current context is) in a less dangerous
> way by allowing to update annotated ranges in another wave and further
> more make it possible to bring waves outside of the current context
> into context.
> - Sunset the existing robots cron mechanism
> After we open the Robot Gateway, the basic wave cron system will no
> longer be needed since robots could use Google App Engine's native
> cron system or the Google App Engine Task Queue API.
> - Gateway support
> Improve the current tweety type of access to support outside
> addresses of the form address+ro...@appspot.com. These addresses will
> come with their own profiles and will make it possible to better
> support actions on behalf of external entities.
> Gadgets
> - Full OpenSocial gadget support
> While we already support the underlying gadget XML and related
> features, we will add full support for the OpenSocial JavaScript
> library (i.e. feature requires="opensocial-0.9")
> This includes a mapping of the OpenSocial concepts onto the wave
> concepts and supporting the actual OpenSocial APIs as well as
> gadgets.io.makeRequest.
> - DiffOnOpen/Playback state mode for gadgets
> Gagdets currently automatically support playback, but sometimes you
> want to be able to do something explicitly (e.g. in a chess game show
> the previous place of a piece). The same goes for diff-on-open.
> Currently gadgets only show the current state - with diff-on-open
> support they will be able to show the user what has changed since last
> time.
> - Google Web Toolkit (GWT) gadgets
> For complex gadgets, GWT is a rather nice way to develop. We'll
> provide a library to build gadgets inside of GWT and a small framework
> to run the same code outside of wave to make debugging with an actual
> debugger possible.
> Embed
> - Expanded UI configuration:
> Switches to display toolbar, participant list, bottom tools.
> - Methods to switch the wave in and out of edit mode
> - Stretch goal: Read-only anonymous access so people don't have to be
> logged into Google Wave to see embedded waves.
> Future Thoughts
> Following September 30th, we have several things in mind, but it'll be
> important to see what gets built in the meantime and hear your
> feedback on the APIs as things evolve.
> Some ideas we're currently thinking about for later in the year:
> - Expand the number of hooks extensions can plug into (via regular
> expressions)
> - Enable robots that aren't required to use Google App Engine
> - Provide an API for robots to access attachments, search and contact
> - Explore tools for improving the robot development/debug experience
> - Expand the embedding API to cover more use cases
> Thanks for the update, Douwe. Looks quite promising and addresses
> many of the limitations in the current API. A few other items for
> consideration:
> - Enable robots to obtain a permanent wave/wavelet/blip ID upon
> creation, rather than the complicated callback mechanism required
> today
> - Publically immutable regions in a wave/wavelet/blip. I have
> encountered use cases where a robot needs to maintain in-wave state
> that also requires specific positioning in a blip and/or total control
> of a blip. "Non-visual" state can currently be managed using data
> documents or back-end persistence, but it would be ideal to be able to
> have robots (and people) create blips and wavelets that can only be
> modified by themselves
> - HTML "islands" in TextView elements (it sounds like you're
> considering a first version of this in the Sept 30th release)
> - Intra-wave hyperlinking (e.g. anchors within a wave that can be used
> for navigation inside a single wave)
> - Structured templates for waves to provide for specific layout/
> styling scenarios that could allow waves to visually and structurally
> emulate well-known collaborative document models such as Wikis,
> discussion groups, microblogs/blogs, etc...this might include styling
> based on "level"/depth of the wavelet/blip, limitations on where/how
> to reply or append content, which content to display in blips
> - The ability to display "inline history" in waves. The "who, what
> and when" of blip submittals is captured, so it would be nice to
> enable this to be displayed in the wave based on styling/preferences.
> This would tie in nicely with the item above.
> - It would be useful to provide something analogous to "mime types" or
> "document types" to enable semantic understanding of a wave's content
> in certain use cases. While this could be accomplished with tags,
> there should be a higher level, more structured approach
> Just a few thoughts, hope you find them useful.
> Rick
> On Aug 12, 1:04 am, "Douwe Osinga (google)" <douwe.osi...@gmail.com>
> wrote:
>> Hi everyone,
>> Leading up to extending the Google Wave preview beyond developers (on
>> September 30th), we wanted to provide some more specific guidance
>> about the things we're working on with the Google Wave APIs. We're
>> working hard to balance stability and reliability of the system with
>> adding new API features and fixing the existing bugs.
>> As a brief review, here are some recent things we've done related to
>> the APIs:
>> * Improved the extension manifest file
>> * Made it easy to create extension installers (the "puzzle piece"
>> wave). From the debug menu, simply select "Add Extension Installer"
>> * Open sourced the Java Robots API
>> * Implemented Context for robots
>> * Added a hover menu to gadgets
>> * Append content to document with simple HTML
>> * Initial robot to gadget communication (though it still needs some
>> work!)
>> We're excited by the early developments we've seen thus far, and look
>> forward to getting more feedback on the existing APIs and the roadmap
>> below.
>> - - -
>> Douwe
>> Google Wave API Tech Lead
>> *Extensions*
>> Design good flow for adding extensions, which includes:
>> - Enabling users to easily discover extension installers
>> - Browsing experience for insert gadgets and robots from a gallery
>> - Enabling user management of their installed extensions (& easily de-
>> install)
>> - Stretch goal: Expand the extension system with more hooks and
>> actions.
>> The goal, in the short term, is to make it easier for a given
>> extension to hook into conversations without being actively added to
>> wave. For example, right now you can insert a YouTube gadget from a
>> link to a YouTube video. We'll open it up to let an extension trigger
>> on a regular expression over any link, so you can build all types of
>> "previewers." This mechanism will not just trigger for link
>> annotations, but for any annotation.
>> Robots
>> - New Robots wire protocol (v0.2)
>> Shortly we will publish the proposed next version of the robots wire
>> protocol. We'd love to get your feedback prior to implementing it.
>> - Java and Python API parity
>> Getting the two APIs to have feature parity
>> - Robot Gateway / OpenSocial RPC Access
>> Robots only react to events right now. By allowing the robots to
>> authenticate themselves through the OpenSocial RPC protocol, robots
>> can create and retrieve waves without being triggered by the wave
>> system first, which will allow for more "active" robots.
>> - Better multiple wave access
>> Right now it is hard to create robots that keep multiple waves in
>> sync. We'll add support to updates waves "blindly" (i.e. without
>> knowing for sure what their current context is) in a less dangerous
>> way by allowing to update annotated ranges in another wave and further
>> more make it possible to bring waves outside of the current context
>> into context.
>> - Sunset the existing robots cron mechanism
>> After we open the Robot Gateway, the basic wave cron system will no
>> longer be needed since robots could use Google App Engine's native
>> cron system or the Google App Engine Task Queue API.
>> - Gateway support
>> Improve the current tweety type of access to support outside
>> addresses of the form address+ro...@appspot.com. These addresses will
>> come with their own profiles and will make it possible to better
>> support actions on behalf of external entities.
>> Gadgets
>> - Full OpenSocial gadget support
>> While we already support the underlying gadget XML and related
>> features, we will add full support for the OpenSocial JavaScript
>> library (i.e. feature requires="opensocial-0.9")
>> This includes a mapping of the OpenSocial concepts onto the wave
>> concepts and supporting the actual OpenSocial APIs as well as
>> gadgets.io.makeRequest.
>> - DiffOnOpen/Playback state mode for gadgets
>> Gagdets currently automatically support playback, but sometimes you
>> want to be able to do something explicitly (e.g. in a chess game show
>> the previous place of a piece). The same goes for diff-on-open.
>> Currently gadgets only show the current state - with diff-on-open
>> support they will be able to show the user what has changed since last
>> time.
>> - Google Web Toolkit (GWT) gadgets
>> For complex gadgets, GWT is a rather nice way to develop. We'll
>> provide a library to build gadgets inside of GWT and a small framework
>> to run the same code outside of wave to make debugging with an actual
>> debugger possible.
>> Embed
>> - Expanded UI configuration:
>> Switches to display toolbar, participant list, bottom tools.
>> - Methods to switch the wave in and out of edit mode
>> - Stretch goal: Read-only anonymous access so people don't have to be
>> logged into Google Wave to see embedded waves.
>> Future Thoughts
>> Following September 30th, we have several things in mind, but it'll be
>> important to see what gets built in the meantime and hear your
>> feedback on the APIs as things evolve.
>> Some ideas we're currently thinking about for later in the year:
>> - Expand the number of hooks extensions can plug into (via regular
>> expressions)
>> - Enable robots that aren't required to use Google App Engine
>> - Provide an API for robots to access attachments, search and contact
>> - Explore tools for improving the robot development/debug experience
>> - Expand the embedding API to cover more use cases
If I'm reading this correct then, we don't need to develop apps on App
Engine any more, when the gateway support will be changed.
Will make some robots easier to make.
A team of 9 of us over the weekend had a basic proof-of-concept robot, PoppyWave, working to add external participants to a wave via their email addresses. These external participants then receive wave updates in their email box and can even reply with their replies being added with attribution as new blips in the corresponding wave.
If you would like to know more, please contact me directly rather than replying to the entire list again.
> Leading up to extending the Google Wave preview beyond developers (onSeptember30th), we wanted to provide some more specific guidance
> about the things we're working on with the Google Wave APIs. We're
> working hard to balance stability and reliability of the system with
> adding new API features and fixing the existing bugs.
> As a brief review, here are some recent things we've done related to
> the APIs:
> * Improved the extension manifest file
> * Made it easy to create extension installers (the "puzzle piece"
> wave). From the debug menu, simply select "Add Extension Installer"
> * Open sourced the Java Robots API
> * Implemented Context for robots
> * Added a hover menu to gadgets
> * Append content to document with simple HTML
> * Initial robot to gadget communication (though it still needs some
> work!)
> We're excited by the early developments we've seen thus far, and look
> forward to getting more feedback on the existing APIs and the roadmap
> below.
> - - -
> Douwe
> Google Wave API Tech Lead
> *Extensions*
> Design good flow for adding extensions, which includes:
> - Enabling users to easily discover extension installers
> - Browsing experience for insert gadgets and robots from a gallery
> - Enabling user management of their installed extensions (& easily de-
> install)
> - Stretch goal: Expand the extension system with more hooks and
> actions.
> The goal, in the short term, is to make it easier for a given
> extension to hook into conversations without being actively added to
> wave. For example, right now you can insert a YouTube gadget from a
> link to a YouTube video. We'll open it up to let an extension trigger
> on a regular expression over any link, so you can build all types of
> "previewers." This mechanism will not just trigger for link
> annotations, but for any annotation.
> Robots
> - New Robots wire protocol (v0.2)
> Shortly we will publish the proposed next version of the robots wire
> protocol. We'd love to get your feedback prior to implementing it.
> - Java and Python API parity
> Getting the two APIs to have feature parity
> - Robot Gateway / OpenSocial RPC Access
> Robots only react to events right now. By allowing the robots to
> authenticate themselves through the OpenSocial RPC protocol, robots
> can create and retrieve waves without being triggered by the wave
> system first, which will allow for more "active" robots.
> - Better multiple wave access
> Right now it is hard to create robots that keep multiple waves in
> sync. We'll add support to updates waves "blindly" (i.e. without
> knowing for sure what their current context is) in a less dangerous
> way by allowing to update annotated ranges in another wave and further
> more make it possible to bring waves outside of the current context
> into context.
> - Sunset the existing robots cron mechanism
> After we open the Robot Gateway, the basic wave cron system will no
> longer be needed since robots could use Google App Engine's native
> cron system or the Google App Engine Task Queue API.
> - Gateway support
> Improve the current tweety type of access to support outside
> addresses of the form address+ro...@appspot.com. These addresses will
> come with their own profiles and will make it possible to better
> support actions on behalf of external entities.
> Gadgets
> - Full OpenSocial gadget support
> While we already support the underlying gadget XML and related
> features, we will add full support for the OpenSocial JavaScript
> library (i.e. feature requires="opensocial-0.9")
> This includes a mapping of the OpenSocial concepts onto the wave
> concepts and supporting the actual OpenSocial APIs as well as
> gadgets.io.makeRequest.
> - DiffOnOpen/Playback state mode for gadgets
> Gagdets currently automatically support playback, but sometimes you
> want to be able to do something explicitly (e.g. in a chess game show
> the previous place of a piece). The same goes for diff-on-open.
> Currently gadgets only show the current state - with diff-on-open
> support they will be able to show the user what has changed since last
> time.
> - Google Web Toolkit (GWT) gadgets
> For complex gadgets, GWT is a rather nice way to develop. We'll
> provide a library to build gadgets inside of GWT and a small framework
> to run the same code outside of wave to make debugging with an actual
> debugger possible.
> Embed
> - Expanded UI configuration:
> Switches to display toolbar, participant list, bottom tools.
> - Methods to switch the wave in and out of edit mode
> - Stretch goal: Read-only anonymous access so people don't have to be
> logged into Google Wave to see embedded waves.
> Future Thoughts
> FollowingSeptember30th, we have several things in mind, but it'll be
> important to see what gets built in the meantime and hear your
> feedback on the APIs as things evolve.
> Some ideas we're currently thinking about for later in the year:
> - Expand the number of hooks extensions can plug into (via regular
> expressions)
> - Enable robots that aren't required to use Google App Engine
> - Provide an API for robots to access attachments, search and contact
> - Explore tools for improving the robot development/debug experience
> - Expand the embedding API to cover more use cases
