Office Hours Transcript: 2009-08-26
2 views
Skip to first unread message
Austin Chau
Aug 26, 2009, 4:21:20 PM8/26/09
to Google Wave API
Office Hours, 2009-08-26 [Now Closed]
Welcome to API office hours! Our door is open ...
Pleasetoppost your question or comment about the robot, gadget, or
embed API to make sure we see it. You can do so by replying to this
blip.
A transcript of this wave will be made publicly available. If you
don't want to appear in the transcript, delete your blip after getting
a response. Be careful not to remove neighboring blips.
tag:office-hours
12:04 pm
Vadim Barsukov:
This is no question about the API, of course, but many users have the
questions: What will happen with Google Wave Sandbox, when the server
wave.google.com starts working?
Survives our accounts and whether they will be transferred to a
production server? I see that Steph Hannon is here. Can I ask them? :)
12:05 pm
Maxim Vasiliev:
now you see only avatar of her...
it's all over now :)
12:06 pm
Vadim Barsukov:
Thank you, Max, I already knew it. Pity!
11:44 am
Lynn Monson:
I've been examining the implementation details of Robot invocation.
One puzzle I have not solved yet is whether or not a Robot can
enumerate the wavelets of a wave independent of specific events. That
is, suppose Robot A has access to wavelet B. When an event occurs on
wavelet B, is there some mechanism for Robot A to access not only
wavelet B, but wavelet C (either with or without being a participant
on C)? The answer seems to be no because the data associated with
wavelet C is not posted to the robot for event processing. Is that
correct?
11:53 am
Marcel Prasetya:
Correct. There's two separate issues here. Robot A can't access
wavelet C since it's not a participant of C.
We are working on opening up a JSON-RPC endpoint that robot can call
to execute operations. Once we have that, we can provide additional
operations like "WAVELET_FETCH" that robot can use to fetch wavelet
content. With that, if there's an event on wavelet B, robot A can
issue an ad-hoc operation to the robot proxy server to fetch wavelet
D, assuming that A is a participant of B and D.
11:53 am
Lynn Monson:
Got it. thanks. I will wait for the JSON-RPC endpoint. Most of my
ideas for robots will require it. Any ETA? ;)
12:02 pm
Marcel Prasetya:
Soon :) We are actively working on it.
11:22 am
Lynn Monson:
As I understand it, each wavelet is composed of any number of
documents. Each document is XML but can be one of two types 1) A rich
text document (aka "blip") or 2) data document. The robot api provides
means to apply operations to the blip documents, but seems to only
provide wholesale replacment capability for data documents. Is that a
limitation of the spec or is it possible (and legal) -- in principle
-- to apply operational transform operations to data documents?
11:28 am
Marcel Prasetya:
Under the hood, data document is just another document, and any
concurrent ops are resolved by our OT stack. However, we haven't
exposed a rich set of APIs for data doc in our client lib.
11:30 am
Lynn Monson:
For much of what I plan to do with wave, I would need to mutate the
data documents. Are there any plans for exposing rich APIs for data
docs? If not, are there any tips about how I could do so? For
clarification: I need to mutate data docs both at the client and at a
robot.
11:32 am
Maxim Vasiliev:
...such data documents are probably need to be displayed somehow.
thats another side of working with data.
or how do you suppose manipulate this data, when it is not just text?
11:34 am
Lynn Monson:
There are a couple of scenarios I can think of for manipulating the
data docs: At the client, for example, you might have a widget that
displays the contents of the data doc in some way. Suppose, for
example, the data ...
11:33 am
Maxim Vasiliev:
nope. widgets are told (some blips above) to do not access wavelet
data.
1:08 pm
Lynn Monson (and Peter LaBanca):
Yes, but my question is why. Widgets actually can access data docs
today via a property get/set mechanism. Why can't a wigdet manipulate
another data doc that is more structured than mere properties?
11:35 am
Maxim Vasiliev:
well... that's is also my question :)
11:37 am
Lynn Monson:
The other hole I see is that *robots* can't access data docs at all
except for wholesale replacements -- the robot api is even more
limited than the widget one.
11:38 am
Maxim Vasiliev:
is it? i don't yet lpayed, but there seems supposed operations like
addElement, insertElement, etc. not DOM but something to manipulate
data.
11:38 am
Lynn Monson:
Perhaps I just missed the api. I'm looking at the Java robot api and
I'm not seeing those methods -- the very ones I hope to see. I hope
I'm just not looking in the right place.
11:39 am
Maxim Vasiliev:
in python it is waveapi.ops.OpBuilder
11:41 am
Lynn Monson:
Yes, there is something like that in the Java API, but it seems to be
an implementation method and not part of the formal, public API. I've
thought of invoking it anyway, but wanted to know if that was above
board.
In fact, the public api has specific methods for data docs which are
wholesale replacement -- perhaps I'm reading too much into those apis
as *precluding* other operations... hmmmm...
I can see all sorts of scenarios where robots might keep additional
data on a wave that isn't displayed to users but is useful. Say, for
example, state data on synchronizing a wave with some external source.
11:45 am
Maxim Vasiliev:
if there's an api to manipulate data, and there will be robot-gadget
communications - this could be usefull combination.
and how do you make data hidden?
11:46 am
Lynn Monson:
I'm assuming that if I create a data document (not a blip), then it
will not be displayed but can be accessed both by robots and by
widgets.
11:48 am
Maxim Vasiliev:
ok. a robot may create a private wavelet. but still no way for gadget
to access it.
see Austin comment below.
/* hm.. still no hyperlinks within the same wave? */
11:49 am
Lynn Monson:
Yes. What I'm thinking is that the robot creates a data document, not
a new wavelet... precisely because the data is really part of the
original wavelet and doesn't warrant creating a new wavelet -- in that
scenario, the widget should be able to access the data document (at
least in principle).
11:51 am
Maxim Vasiliev:
i guess the latter should be posted as feature request. it can solve
alot of tasks....
11:51 am
Lynn Monson:
FWIW... I've been bumping into these need from almost the beginning.
The wave data structures and spec don't need to be changed to
facilitate this -- it's purely an API problem
11:56 am
Maxim Vasiliev:
there was promised that robots can communicate with gadgets some day.
maybe this can eliminate necessity for gadgets to handle data.
11:29 am
Cameron Neylon:
I just wanted to check whether some behaviour is a deliberate feature
or a consequence of something else. As part of a Robot
(chems...@appspot.com) I aim to insert some text and then set the
language of that text to be "chem" for chemistry. Two reasons for
doing this, one is that I want Spelly to stay away from those sections
and the second is that it marks that material as being related to a
particular technical "language" which seems a natural way to do it.
Setting it seems fine. What I'm puzzled about is that it then seems to
be reverted back to English by something either in the client or on
the server. The relevant log file is below:
Incoming operation, DocumentMutation{__77; -- 22; },
Incoming operation, DocumentMutation{__77; (( lang="chem"; +
+"acetoacetate (csid:"; (( link/manual="http://www.chemspider.com/
Chemical-Structure.5341896.html"; ++"5341896"; )) link/manual; ++",
6g, 59.36 millimoles) "; )) lang; },
Incoming operation, DocumentMutation{__77; (( lang="en"; __50; ))
lang; },
Incoming operation, DocumentMutation{__91; (( spell="aa51bc57*
aa51bc57* "; __4; )) spell; },
I could obviously set my own arbitrary annotation but part of the
reason for asking is that it would be nice to keep the log files
cleaner for demos :-)
11:34 am
Marcel Prasetya:
We have an agent (internal robot) that auto annotates the document so
that spelly can make the proper suggestions.
11:37 am
Cameron Neylon:
So that's pretty much fixed behaviour for the moment then? Presumably
no way to tell it not to? As I say, not a major problem but in demos I
am aiming to show people that I could annotate with various
interesting pieces of semantic information and easiest way to show it
is in the log. However all the spell checks kind of litter it up a
bit.
11:39 am
Marcel Prasetya:
Currently there's no way to tell it not to auto annotate the content.
Please file a feature request, and we can bring it up to our spelly
guys :)
11:58 am
Maxim Vasiliev:
i thouhgt it was discussed at end of "under hood" and this feature
already implemented
11:40 am
Cameron Neylon:
Cheers. Will do that. Thanks for the info. Good to know that I'm not
just going mad :-)
11:13 am
Maxim Vasiliev:
I'm aching about gadgets fate
are gadgets intentionaly made shared-stated and concurrently-changed
or they are supposed to be more collaborative some day?
/* through some kind of synchronization/resolving concurrent actions
*/
and whether will gadgets API support xml state instead of strings
maps?
will gadgets be able to monitor and modify wavelet content?
11:07 am
Chad Burt:
Hello,
I'd like to get some advice on a use case that doesn't seem to be
addressed by the current APIs, but I think is a really important one.
I'm working on an app that needs much tighter integration with wave
than currently afforded by the embed API. Essentially, the ability to
listen for events from the currently active wave and modify the
surrounding application's state (or sync it back to the wave). The
webapp would act as a javascript robot.
Is this something that seems appropriate for the embed API to support,
or something that would have to be done with a custom client?
11:11 am
Marcel Prasetya:
You can use a combination of our embed and robot API to do this. So
you will have an embedded wave that has your robot as a participant.
When your robot gets notified for an event, it can make an HTTP call
to your server. Also, we are actively working on opening up a JSON-RPC
endpoint for our robot API, so that your robot can make an
authenticated, ad-hoc, call to our server to execute operations.
11:14 am
Chad Burt:
awesome, JSON-RPC seems like the way to go for my app.
To give a bit more context: We're doing something similar to the
embedded map annotation demo, but a full blown web GIS using the Earth
API. The map exists outside of Wave, but we'd want very fast updates
based on people pasting in kml or doing other operations with the GIS
client.
Of course, it would be nice to make the Wave useful outside the
context of our tool, so we'd have to work out a sort of progressive
enhancement scheme where you may see a basic map on your mobile or in
the vanilla wave client, and an enhanced version when using our
website
11:17 am
Chad Burt:
I guess a problem with supporting this with the JSON-RPC method is
that, while map updates on our client can be pushed to the wave
server, updating the wave, there is no way for the other users to have
their map update when the wave is modified on their end. It still
really comes down to needing event listeners on the wavePanel
instance, right?
11:24 am
Marcel Prasetya:
I guess there's probably two potential hacky ways to solve this:
1. Make your map as a gadget, embedded inside an embedded wave :)
2. Put a "hidden" gadget inside the embedded wave, that contains an
iframe (of the same domain as your app), that can be used to
communicate changes (similar to gadgets.rpc).
11:26 am
Chad Burt:
Okay, I think I need to do some reading up on iframes then. Thanks.
It is hacky though :) Is this something that you foresee as always
being hacky, or is this kind of integration between wave and a webapp
within the domain of what googlers envision for the tool?
11:27 am
Chad Burt:
In other words, should I make an effort to really document this use
case and stick something on the mailing list?
11:30 am
Marcel Prasetya:
Please do. The approaches that I mentioned were hack++. I don't think
they can be a viable long term solution :)
11:31 am
Chad Burt:
great! Hopefully I can get a demo working with those approaches that
will make it clear how awesome it would be if that sort of thing was
easier.
11:27 am
Maxim Vasiliev:
in extension gallery there're pair of such examples with iframe
http://wave-ide.appspot.com/html.xml - Embed any HTML into a wave.
http://wave-ide.appspot.com/iframe.xml - Embed any web page (as
<iframe>) into a wave
11:32 am
Chad Burt:
thanks for the links
11:04 am
Jurrien Stutterheim:
Is, or will it be possible to get the wave ID using the Gadget API?
This would be awesome for integrating it in external applications.
11:05 am
me:
Hi Jurrien, the way to do that is via Robot interaction. Gadgets are
designed in such a way to be just an embedded html + js, with no
direct access to wave-specific data (other than the gadget states).
But you can certainly do that with a gadget-robot communciation.
11:16 am
Maxim Vasiliev:
does gadget-robo communication alerady works?
11:18 am
me:
Yes. Gadget state updates trigger DOCUMENT_CHANGED event on the robot.
If the robot is subscribed to the event, it can programmatically fetch
the gadget state values.
11:21 am
Maxim Vasiliev:
that opens very qurious way to interact with robots...
but how can robot change gadget state?
11:23 am
Avital Oliver:
As far as I know, currently a robot can only remove a gadget and
insert a new one in place of it. Any plans for supporting direct
gadget state manipulation by robots?
11:30 am
Marcel Prasetya:
Hi Avital, what's up? Yes, that's in the work :)
11:41 am
Maxim Vasiliev:
that's shiny! :)
11:16 am
Jurrien Stutterheim:
Hmm.. the wave API does offer wave.getParticipants(), amongst some
other wave-specific data.
11:16 am
me:
Yes, participants are exposed. So you are correct, any data other than
participants.
11:19 am
Jurrien Stutterheim:
Thanks for all the wisdom Austin. I'm going to see how I can apply it
to my plans to conquer the world ;)
11:21 am
me:
happy conquering :)
11:11 am
Jurrien Stutterheim:
Ah I see. Thanks. I did see that possibility, but I wanted to keep
things as simple as possible. There is mention of new Gadget APIs
coming ni the (near) future in the documentation, which relate to the
Wave itself. What would that API be? Sorry, scratch that. It mentioned
that there is no programmatic access at this time for gadget owner
data.
11:11 am
me:
that is correct. Wave gadget is self-contained with its own set of
data as gadget states.
11:22 am
Maxim Vasiliev:
[from above bleep] willl gadget state evolve to XML (as it was
intended at times of google i/o) ?
11:24 am
me:
do you mean at the actual data format of the gadget states would
become XML instead of flat text?
11:28 am
Maxim Vasiliev:
exactly this. string maps may appear to be far not enough
11:33 am
me:
I am not sure if that is something we are considering. Feel free to
submit feature request for this.
11:04 am
Maxim Vasiliev:
is it intended to make user agent API somewhat standartized and
published?
/* so that extension developers could implement various features like
Spelly's hints, G+ context menues, w:stuff elements, etc. */
or otherwise - all those fancy features are left completely at
discretion of particular client developers?
/* this may evolve to somewhat federablessness dependencies between
user agent clients and service robots */
11:07 am
Marcel Prasetya:
We haven't put a lot of thought on this, but something that we are
planning to do is to have a collection of standardized "UI elements"
that extension/robot developer can pick and choose. Once we have that,
I think it will make sense to standardize the format.
11:09 am
Maxim Vasiliev:
but we all see, hidden Spelly works well with his hints, and G+ menues
work. are those ui elements still in hard developement stage?
11:12 am
Marcel Prasetya:
Yes, and we haven't had a chance to generalized them yet, to be used
for other extensions.
11:15 am
Maxim Vasiliev:
in any way, i guess this would be done throught hairy annotations?
11:18 am
Marcel Prasetya:
I think it would be a combination of annotation (for non-block stuff)
and XML element (for block).
11:02 am
Avital Oliver:
Good morning. As far as I understand, the embed API forces you to pre-
define a height for the iframe containing the wave. Could there be a
feature to allow auto-heights (similar to the gadget API)?
11:08 am
me:
Hi, the embed iframe is little different from gadget, since embed is
iframed into an external party website. You can file a feature request
and we will explore this further -
http://code.google.com/p/google-wave-resources/issues/list?can=1&q=&sort=-id&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary
11:13 am
Ayal Gelles:
Yes. I would have expected that an embedded wave would expose some
more functionality and information to the layer which is embedding it.
11:14 am
me:
I understand what you mean, yea there are ways to ge the computed
height of the embedded wave. This could be a feature enhancement in
the feature. But at the moment, we want the owner of the website to
determine how tall they want the embed iframe to be.
11:39 am
Vadim Barsukov:
I have a simple question in this regard. What can be used function
getFrameId() from Google Wave Embed API?
For example, to gain access to the iframe via DOM?
11:41 am
Avital Oliver:
The iframe is on another domain, you won't be able to access its
children.
11:53 am
Vadim Barsukov:
In this case, what may need this feature, this function? How can it be
used?
11:57 am
Marcel Prasetya:
Purely speculative, but with this method you can get a handler to the
"iframe" element, and probably attach event handlers :)
11:18 am
Avital Oliver:
Could it be simpler to just allow the embed API to return the computed
wave height? It's currently impossible due to cross-domain
restrictions (if we were to try to do it ourselves).
11:19 am
me:
I agree, if such a thing were to be done it's best to be provided by
us :) feel free to add that as a feature request against the Embed
API.
11:22 am
Ayal Gelles:
thanks austin. just want to emphasize the fact that it is impossible
to compute it without any special support in the api.
11:04 am
Monika Adamczyk:
there was discussion about draft checkbox today - when this
functionality is enabled, will it transmit message right away or will
keep it local in the client until submitted?
11:43 am
me:
The functionality regarding draft checkbox is still under
consideration, we will update you guys as soon as it is more
finalized.
11:55 am
Javier Fernandez:
I would like to change the avatar and the name that appears in the
contacts list of the robot I have created. Can anyone help me? Thanks!
11:58 am
Marcel Prasetya:
Java or Python?
11:58 am
Javier Fernandez:
Java
11:59 am
Javier Fernandez:
I have tried to search for a tutorial or an example, but I haven't
found any.
12:01 pm
Marcel Prasetya:
Check out slide 11 at http://tinyurl.com/waverobotapi :)
Alternatively, Tweety and Polly have an example on this.
12:01 pm
Javier Fernandez:
OK, thanks!!!!!!!!!!
Welcome to API office hours! Our door is open ...
Pleasetoppost your question or comment about the robot, gadget, or
embed API to make sure we see it. You can do so by replying to this
blip.
A transcript of this wave will be made publicly available. If you
don't want to appear in the transcript, delete your blip after getting
a response. Be careful not to remove neighboring blips.
tag:office-hours
12:04 pm
Vadim Barsukov:
This is no question about the API, of course, but many users have the
questions: What will happen with Google Wave Sandbox, when the server
wave.google.com starts working?
Survives our accounts and whether they will be transferred to a
production server? I see that Steph Hannon is here. Can I ask them? :)
12:05 pm
Maxim Vasiliev:
now you see only avatar of her...
it's all over now :)
12:06 pm
Vadim Barsukov:
Thank you, Max, I already knew it. Pity!
11:44 am
Lynn Monson:
I've been examining the implementation details of Robot invocation.
One puzzle I have not solved yet is whether or not a Robot can
enumerate the wavelets of a wave independent of specific events. That
is, suppose Robot A has access to wavelet B. When an event occurs on
wavelet B, is there some mechanism for Robot A to access not only
wavelet B, but wavelet C (either with or without being a participant
on C)? The answer seems to be no because the data associated with
wavelet C is not posted to the robot for event processing. Is that
correct?
11:53 am
Marcel Prasetya:
Correct. There's two separate issues here. Robot A can't access
wavelet C since it's not a participant of C.
We are working on opening up a JSON-RPC endpoint that robot can call
to execute operations. Once we have that, we can provide additional
operations like "WAVELET_FETCH" that robot can use to fetch wavelet
content. With that, if there's an event on wavelet B, robot A can
issue an ad-hoc operation to the robot proxy server to fetch wavelet
D, assuming that A is a participant of B and D.
11:53 am
Lynn Monson:
Got it. thanks. I will wait for the JSON-RPC endpoint. Most of my
ideas for robots will require it. Any ETA? ;)
12:02 pm
Marcel Prasetya:
Soon :) We are actively working on it.
11:22 am
Lynn Monson:
As I understand it, each wavelet is composed of any number of
documents. Each document is XML but can be one of two types 1) A rich
text document (aka "blip") or 2) data document. The robot api provides
means to apply operations to the blip documents, but seems to only
provide wholesale replacment capability for data documents. Is that a
limitation of the spec or is it possible (and legal) -- in principle
-- to apply operational transform operations to data documents?
11:28 am
Marcel Prasetya:
Under the hood, data document is just another document, and any
concurrent ops are resolved by our OT stack. However, we haven't
exposed a rich set of APIs for data doc in our client lib.
11:30 am
Lynn Monson:
For much of what I plan to do with wave, I would need to mutate the
data documents. Are there any plans for exposing rich APIs for data
docs? If not, are there any tips about how I could do so? For
clarification: I need to mutate data docs both at the client and at a
robot.
11:32 am
Maxim Vasiliev:
...such data documents are probably need to be displayed somehow.
thats another side of working with data.
or how do you suppose manipulate this data, when it is not just text?
11:34 am
Lynn Monson:
There are a couple of scenarios I can think of for manipulating the
data docs: At the client, for example, you might have a widget that
displays the contents of the data doc in some way. Suppose, for
example, the data ...
11:33 am
Maxim Vasiliev:
nope. widgets are told (some blips above) to do not access wavelet
data.
1:08 pm
Lynn Monson (and Peter LaBanca):
Yes, but my question is why. Widgets actually can access data docs
today via a property get/set mechanism. Why can't a wigdet manipulate
another data doc that is more structured than mere properties?
11:35 am
Maxim Vasiliev:
well... that's is also my question :)
11:37 am
Lynn Monson:
The other hole I see is that *robots* can't access data docs at all
except for wholesale replacements -- the robot api is even more
limited than the widget one.
11:38 am
Maxim Vasiliev:
is it? i don't yet lpayed, but there seems supposed operations like
addElement, insertElement, etc. not DOM but something to manipulate
data.
11:38 am
Lynn Monson:
Perhaps I just missed the api. I'm looking at the Java robot api and
I'm not seeing those methods -- the very ones I hope to see. I hope
I'm just not looking in the right place.
11:39 am
Maxim Vasiliev:
in python it is waveapi.ops.OpBuilder
11:41 am
Lynn Monson:
Yes, there is something like that in the Java API, but it seems to be
an implementation method and not part of the formal, public API. I've
thought of invoking it anyway, but wanted to know if that was above
board.
In fact, the public api has specific methods for data docs which are
wholesale replacement -- perhaps I'm reading too much into those apis
as *precluding* other operations... hmmmm...
I can see all sorts of scenarios where robots might keep additional
data on a wave that isn't displayed to users but is useful. Say, for
example, state data on synchronizing a wave with some external source.
11:45 am
Maxim Vasiliev:
if there's an api to manipulate data, and there will be robot-gadget
communications - this could be usefull combination.
and how do you make data hidden?
11:46 am
Lynn Monson:
I'm assuming that if I create a data document (not a blip), then it
will not be displayed but can be accessed both by robots and by
widgets.
11:48 am
Maxim Vasiliev:
ok. a robot may create a private wavelet. but still no way for gadget
to access it.
see Austin comment below.
/* hm.. still no hyperlinks within the same wave? */
11:49 am
Lynn Monson:
Yes. What I'm thinking is that the robot creates a data document, not
a new wavelet... precisely because the data is really part of the
original wavelet and doesn't warrant creating a new wavelet -- in that
scenario, the widget should be able to access the data document (at
least in principle).
11:51 am
Maxim Vasiliev:
i guess the latter should be posted as feature request. it can solve
alot of tasks....
11:51 am
Lynn Monson:
FWIW... I've been bumping into these need from almost the beginning.
The wave data structures and spec don't need to be changed to
facilitate this -- it's purely an API problem
11:56 am
Maxim Vasiliev:
there was promised that robots can communicate with gadgets some day.
maybe this can eliminate necessity for gadgets to handle data.
11:29 am
Cameron Neylon:
I just wanted to check whether some behaviour is a deliberate feature
or a consequence of something else. As part of a Robot
(chems...@appspot.com) I aim to insert some text and then set the
language of that text to be "chem" for chemistry. Two reasons for
doing this, one is that I want Spelly to stay away from those sections
and the second is that it marks that material as being related to a
particular technical "language" which seems a natural way to do it.
Setting it seems fine. What I'm puzzled about is that it then seems to
be reverted back to English by something either in the client or on
the server. The relevant log file is below:
Incoming operation, DocumentMutation{__77; -- 22; },
Incoming operation, DocumentMutation{__77; (( lang="chem"; +
+"acetoacetate (csid:"; (( link/manual="http://www.chemspider.com/
Chemical-Structure.5341896.html"; ++"5341896"; )) link/manual; ++",
6g, 59.36 millimoles) "; )) lang; },
Incoming operation, DocumentMutation{__77; (( lang="en"; __50; ))
lang; },
Incoming operation, DocumentMutation{__91; (( spell="aa51bc57*
aa51bc57* "; __4; )) spell; },
I could obviously set my own arbitrary annotation but part of the
reason for asking is that it would be nice to keep the log files
cleaner for demos :-)
11:34 am
Marcel Prasetya:
We have an agent (internal robot) that auto annotates the document so
that spelly can make the proper suggestions.
11:37 am
Cameron Neylon:
So that's pretty much fixed behaviour for the moment then? Presumably
no way to tell it not to? As I say, not a major problem but in demos I
am aiming to show people that I could annotate with various
interesting pieces of semantic information and easiest way to show it
is in the log. However all the spell checks kind of litter it up a
bit.
11:39 am
Marcel Prasetya:
Currently there's no way to tell it not to auto annotate the content.
Please file a feature request, and we can bring it up to our spelly
guys :)
11:58 am
Maxim Vasiliev:
i thouhgt it was discussed at end of "under hood" and this feature
already implemented
11:40 am
Cameron Neylon:
Cheers. Will do that. Thanks for the info. Good to know that I'm not
just going mad :-)
11:13 am
Maxim Vasiliev:
I'm aching about gadgets fate
are gadgets intentionaly made shared-stated and concurrently-changed
or they are supposed to be more collaborative some day?
/* through some kind of synchronization/resolving concurrent actions
*/
and whether will gadgets API support xml state instead of strings
maps?
will gadgets be able to monitor and modify wavelet content?
11:07 am
Chad Burt:
Hello,
I'd like to get some advice on a use case that doesn't seem to be
addressed by the current APIs, but I think is a really important one.
I'm working on an app that needs much tighter integration with wave
than currently afforded by the embed API. Essentially, the ability to
listen for events from the currently active wave and modify the
surrounding application's state (or sync it back to the wave). The
webapp would act as a javascript robot.
Is this something that seems appropriate for the embed API to support,
or something that would have to be done with a custom client?
11:11 am
Marcel Prasetya:
You can use a combination of our embed and robot API to do this. So
you will have an embedded wave that has your robot as a participant.
When your robot gets notified for an event, it can make an HTTP call
to your server. Also, we are actively working on opening up a JSON-RPC
endpoint for our robot API, so that your robot can make an
authenticated, ad-hoc, call to our server to execute operations.
11:14 am
Chad Burt:
awesome, JSON-RPC seems like the way to go for my app.
To give a bit more context: We're doing something similar to the
embedded map annotation demo, but a full blown web GIS using the Earth
API. The map exists outside of Wave, but we'd want very fast updates
based on people pasting in kml or doing other operations with the GIS
client.
Of course, it would be nice to make the Wave useful outside the
context of our tool, so we'd have to work out a sort of progressive
enhancement scheme where you may see a basic map on your mobile or in
the vanilla wave client, and an enhanced version when using our
website
11:17 am
Chad Burt:
I guess a problem with supporting this with the JSON-RPC method is
that, while map updates on our client can be pushed to the wave
server, updating the wave, there is no way for the other users to have
their map update when the wave is modified on their end. It still
really comes down to needing event listeners on the wavePanel
instance, right?
11:24 am
Marcel Prasetya:
I guess there's probably two potential hacky ways to solve this:
1. Make your map as a gadget, embedded inside an embedded wave :)
2. Put a "hidden" gadget inside the embedded wave, that contains an
iframe (of the same domain as your app), that can be used to
communicate changes (similar to gadgets.rpc).
11:26 am
Chad Burt:
Okay, I think I need to do some reading up on iframes then. Thanks.
It is hacky though :) Is this something that you foresee as always
being hacky, or is this kind of integration between wave and a webapp
within the domain of what googlers envision for the tool?
11:27 am
Chad Burt:
In other words, should I make an effort to really document this use
case and stick something on the mailing list?
11:30 am
Marcel Prasetya:
Please do. The approaches that I mentioned were hack++. I don't think
they can be a viable long term solution :)
11:31 am
Chad Burt:
great! Hopefully I can get a demo working with those approaches that
will make it clear how awesome it would be if that sort of thing was
easier.
11:27 am
Maxim Vasiliev:
in extension gallery there're pair of such examples with iframe
http://wave-ide.appspot.com/html.xml - Embed any HTML into a wave.
http://wave-ide.appspot.com/iframe.xml - Embed any web page (as
<iframe>) into a wave
11:32 am
Chad Burt:
thanks for the links
11:04 am
Jurrien Stutterheim:
Is, or will it be possible to get the wave ID using the Gadget API?
This would be awesome for integrating it in external applications.
11:05 am
me:
Hi Jurrien, the way to do that is via Robot interaction. Gadgets are
designed in such a way to be just an embedded html + js, with no
direct access to wave-specific data (other than the gadget states).
But you can certainly do that with a gadget-robot communciation.
11:16 am
Maxim Vasiliev:
does gadget-robo communication alerady works?
11:18 am
me:
Yes. Gadget state updates trigger DOCUMENT_CHANGED event on the robot.
If the robot is subscribed to the event, it can programmatically fetch
the gadget state values.
11:21 am
Maxim Vasiliev:
that opens very qurious way to interact with robots...
but how can robot change gadget state?
11:23 am
Avital Oliver:
As far as I know, currently a robot can only remove a gadget and
insert a new one in place of it. Any plans for supporting direct
gadget state manipulation by robots?
11:30 am
Marcel Prasetya:
Hi Avital, what's up? Yes, that's in the work :)
11:41 am
Maxim Vasiliev:
that's shiny! :)
11:16 am
Jurrien Stutterheim:
Hmm.. the wave API does offer wave.getParticipants(), amongst some
other wave-specific data.
11:16 am
me:
Yes, participants are exposed. So you are correct, any data other than
participants.
11:19 am
Jurrien Stutterheim:
Thanks for all the wisdom Austin. I'm going to see how I can apply it
to my plans to conquer the world ;)
11:21 am
me:
happy conquering :)
11:11 am
Jurrien Stutterheim:
Ah I see. Thanks. I did see that possibility, but I wanted to keep
things as simple as possible. There is mention of new Gadget APIs
coming ni the (near) future in the documentation, which relate to the
Wave itself. What would that API be? Sorry, scratch that. It mentioned
that there is no programmatic access at this time for gadget owner
data.
11:11 am
me:
that is correct. Wave gadget is self-contained with its own set of
data as gadget states.
11:22 am
Maxim Vasiliev:
[from above bleep] willl gadget state evolve to XML (as it was
intended at times of google i/o) ?
11:24 am
me:
do you mean at the actual data format of the gadget states would
become XML instead of flat text?
11:28 am
Maxim Vasiliev:
exactly this. string maps may appear to be far not enough
11:33 am
me:
I am not sure if that is something we are considering. Feel free to
submit feature request for this.
11:04 am
Maxim Vasiliev:
is it intended to make user agent API somewhat standartized and
published?
/* so that extension developers could implement various features like
Spelly's hints, G+ context menues, w:stuff elements, etc. */
or otherwise - all those fancy features are left completely at
discretion of particular client developers?
/* this may evolve to somewhat federablessness dependencies between
user agent clients and service robots */
11:07 am
Marcel Prasetya:
We haven't put a lot of thought on this, but something that we are
planning to do is to have a collection of standardized "UI elements"
that extension/robot developer can pick and choose. Once we have that,
I think it will make sense to standardize the format.
11:09 am
Maxim Vasiliev:
but we all see, hidden Spelly works well with his hints, and G+ menues
work. are those ui elements still in hard developement stage?
11:12 am
Marcel Prasetya:
Yes, and we haven't had a chance to generalized them yet, to be used
for other extensions.
11:15 am
Maxim Vasiliev:
in any way, i guess this would be done throught hairy annotations?
11:18 am
Marcel Prasetya:
I think it would be a combination of annotation (for non-block stuff)
and XML element (for block).
11:02 am
Avital Oliver:
Good morning. As far as I understand, the embed API forces you to pre-
define a height for the iframe containing the wave. Could there be a
feature to allow auto-heights (similar to the gadget API)?
11:08 am
me:
Hi, the embed iframe is little different from gadget, since embed is
iframed into an external party website. You can file a feature request
and we will explore this further -
http://code.google.com/p/google-wave-resources/issues/list?can=1&q=&sort=-id&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary
11:13 am
Ayal Gelles:
Yes. I would have expected that an embedded wave would expose some
more functionality and information to the layer which is embedding it.
11:14 am
me:
I understand what you mean, yea there are ways to ge the computed
height of the embedded wave. This could be a feature enhancement in
the feature. But at the moment, we want the owner of the website to
determine how tall they want the embed iframe to be.
11:39 am
Vadim Barsukov:
I have a simple question in this regard. What can be used function
getFrameId() from Google Wave Embed API?
For example, to gain access to the iframe via DOM?
11:41 am
Avital Oliver:
The iframe is on another domain, you won't be able to access its
children.
11:53 am
Vadim Barsukov:
In this case, what may need this feature, this function? How can it be
used?
11:57 am
Marcel Prasetya:
Purely speculative, but with this method you can get a handler to the
"iframe" element, and probably attach event handlers :)
11:18 am
Avital Oliver:
Could it be simpler to just allow the embed API to return the computed
wave height? It's currently impossible due to cross-domain
restrictions (if we were to try to do it ourselves).
11:19 am
me:
I agree, if such a thing were to be done it's best to be provided by
us :) feel free to add that as a feature request against the Embed
API.
11:22 am
Ayal Gelles:
thanks austin. just want to emphasize the fact that it is impossible
to compute it without any special support in the api.
11:04 am
Monika Adamczyk:
there was discussion about draft checkbox today - when this
functionality is enabled, will it transmit message right away or will
keep it local in the client until submitted?
11:43 am
me:
The functionality regarding draft checkbox is still under
consideration, we will update you guys as soon as it is more
finalized.
11:55 am
Javier Fernandez:
I would like to change the avatar and the name that appears in the
contacts list of the robot I have created. Can anyone help me? Thanks!
11:58 am
Marcel Prasetya:
Java or Python?
11:58 am
Javier Fernandez:
Java
11:59 am
Javier Fernandez:
I have tried to search for a tutorial or an example, but I haven't
found any.
12:01 pm
Marcel Prasetya:
Check out slide 11 at http://tinyurl.com/waverobotapi :)
Alternatively, Tweety and Polly have an example on this.
12:01 pm
Javier Fernandez:
OK, thanks!!!!!!!!!!
Reply all
Reply to author
Forward
0 new messages