Export to GitHub

walkaround - issue #97

I can't export from GWave public waves.


Posted on Apr 8, 2012 by Massive Hippo

I want to export from GWave public waves, that have participant public@a.gwave.com. But when I execute search request "with:public" from robot API, response from server contains only that public waves, where I is participant. Are there any way to resolve this task?

Comment #1

Posted on Apr 10, 2012 by Quick Lion

Are you trying to export all public waves from wave.google.com, even ones that you have never opened?

Comment #2

Posted on Apr 10, 2012 by Massive Hippo

Yes.

Comment #3

Posted on Apr 10, 2012 by Quick Lion

I've never tried using the Robot API for this. It's quite possible that it doesn't work. I don't think this will ever be fixed on the server side.

An alternative approach would be to use the client-server protocol. Some people have reverse-engineered much of it already. I would start with the wave-client-for-emacs code base since I'm familiar with it; but if you don't know Lisp, this may not be a good starting point for you.

Comment #4

Posted on Apr 11, 2012 by Happy Cat

Google Wave Robot API doesn't allow to fetch waves with "implicit" access. But can you explain a bit more the other solution? I actually thought about making Selenium script that would use the browser to search for all public waves and add there a robot.

Comment #5

Posted on Apr 11, 2012 by Quick Lion

The Robot API should allow fetching waves with "implicit" access (public or through groups). I added this feature (security hole?) a few months ago to allow users to export all their waves, not just the ones where they are a participant. The Robot API documentation is probably out of date. If you play around with walkaround's import feature, you should be able to confirm that this works.

The other solution I was referring to is talking to the wave servers the same way Google's browser-based client does -- you need the right authentication cookies and have to speak Wave's undocumented JSON format, the same format the client uses. But, if you reverse-engineer the format, you should be able to send searches for [with:public after:YYYY/MM/DD before:YYYY/MM/DD] (one for each day) to get the IDs for all public waves.

You can then feed these wave IDs into walkaround's or Apache Wave's import logic.

wave-client-for-emacs can already do the authentication handling and speaks parts of the JSON format, that's why I would start with it. There are probably other projects (in more familiar languages) that implement the reverse-engineered client-server protocol, but I don't know about them.

Reverse-engineering the client-server protocol might violate Google's terms of service, so if you do this, your access to Wave may be suspended, or something. I'm not familiar with the terms of service and can't give you any advice on this.

Comment #6

Posted on Apr 14, 2012 by Massive Hippo

Please help me. I try to request all waves up to 31 jan 2012. And I can't list all of them. Request "with:public after:2012/01/31 before:2012/01/31" does not return all waves in the response. If execute this request from Web client, in the title on the waves digest appears "with:public after:2012/01/31 before:2012/01/31 1-35 of lots". Many of waves may be lost, what would you advise?

Comment #7

Posted on Apr 14, 2012 by Massive Hippo

Screenshot is applyed.

Attachments

Comment #8

Posted on Apr 15, 2012 by Quick Lion

You say that the request "with:public after:2012/01/31 before:2012/01/31" does not return all waves in the response. How did you send this request? If it was through the Robot API, then I'm not surprised, and I don't think it will ever work.

Comment #9

Posted on Apr 15, 2012 by Massive Hippo

I send it from Web client. Screenshot is applyed above.

Comment #10

Posted on Apr 15, 2012 by Quick Lion

What's wrong with the list of waves the web client is showing?

Comment #11

Posted on Apr 16, 2012 by Happy Ox

Yes, I attached one more screenshot for the 30 January 2012.

Waves just not loaded.

Attachments

Comment #12

Posted on Apr 17, 2012 by Quick Lion

I tried the search a few times (on Firefox), and it worked about 2/3 of the time. Could be either a client bug or a backend bug, I don't know. It's not going to be fixed. To be safe, you can add a loop in your code to try a few times.

Status: WontFix

Labels:
Type-Defect Priority-Medium