Re: [Google Wave APIs] Re: Delete a wave
The inherent problem with deleting waves is that unlike deleting an email, the wave itself is shared among many users, so you're deleting things out of other people's mailboxes when you delete a wave. I'm not sure that I would like to allow other people to delete waves that I've been adding things to without my permission. For all intents and purposes, trashing a wave should be fine. On Fri, Dec 4, 2009 at 9:50 PM, fabrizio-mc wrote: > The problem is that a robot (like the one I coded) who has to > periodically check for waves and update them with external data > continue to update trashed waves if no one of the partecipants remove > it from wave before trash the wave... > I hope that permanent deletion will be available soon. > > -- > > You received this message because you are subscribed to the Google Groups > "Google Wave API" group. > To post to this group, send email to google-wave-...@googlegroups.com. > To unsubscribe from this group, send email to > google-wave-api+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-wave-api?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to google-wave-...@googlegroups.com. To unsubscribe from this group, send email to google-wave-api+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en.
Re: [Google Wave APIs] Re: Storage of Waves?
Pete, Currently, you can set up a wave server (there is some open source code to create one), and wave with other users on that system without sharing information with the google servers. However the wave front end client that is at http://wave.google.com won't connect to that server, so the functionality is very limited. There is one very simple text-based front end client included in the open-source release, but it's not nearly as functional as the web-based client that Google is hosting. To download the open source wave server, check out http://code.google.com/p/wave-protocol/. As far as I can tell, there is no wave equivalent of POP or IMAP yet, only a wave equivalent of SMTP (the Federation protocol). This is currently hindering the development of front end applications for Wave, which would make your scenario possible. It's exactly the same as setting up your own private Exchange/Lotus Notes/sendmail email server at work. You can be sure that no emails will pass through GMail's servers as long as you don't email someone at Gmail, however if POP and IMAP are firewalled off of your server, you can't use GMail to check the email on your private email server without first forwarding it to your GMail account (and thus hosting it on Google's servers) On Wed, Dec 2, 2009 at 11:10 AM, pedron wrote: > > So, i'm not trying to be thick, but just to clarify: > > I currently cannot set up, for instance, Google Wave on a server in my > private network. I must have access to the internet currently and > Google hosts all Waves currently. However, with any luck this may > change in the future? are there plans for this? > > I REALLY appreciate the straight answer. I read about it, but couldn't > seem to get the info i needed. thanks! > > -- > > You received this message because you are subscribed to the Google Groups > "Google Wave API" group. > To post to this group, send email to google-wave-...@googlegroups.com. > To unsubscribe from this group, send email to > google-wave-api+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-wave-api?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to google-wave-...@googlegroups.com. To unsubscribe from this group, send email to google-wave-api+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en.
Re: [Google Wave APIs] Re: Programmatically creating waves, was: Will other panel's functionality be exposed?
I think you missed the point that I was making... There is no JSON RPC endpoint on the wave.google.com system that is accessible to the robots. wave.google.com is an RPC "client" as far as the robot is concerned, and (based on the API that's currently available) cannot initiate requests to the server to create waves, blips, or anything like that. It's only conduit to cause the server to do something is in response to a request from Wave.google.com. The way that it creates blips on the server is by sending a command back through the response which tells the server to create a blip, but again, this response is part of the same HTTP stream that notified the robot of the event. If you're receiving outside events in your robot, then it cannot respond to wave.google.com with changes, because the request didn't come from wave.google.com, it came from your external event source. It could queue up responses that should happen, and send them along to wave.google.com the next time wave.google.com makes a request, but there are simpler and more elegant ways of solving that problem (such as implementing your own federation server, which can modify waves in it's posession all it wants, and add participants on any of the servers it's federated to as recipients. On Tue, Nov 17, 2009 at 12:19 PM, Olreich wrote: > If we can't push new data to waves, then we can't delete or create new > blips. The thing is, we're currently stuck in an event loop that the > server makes fire upon events. But, if one were to send a JSON RPC > message to the server, the server should just fire it and not really > care if it's in response to a event, or if the robot is just doing it > because it wants to. (obviously there is authentication). The only > problem with this is that the robot is a new instance in every wave, > though one instance should be able to play with another instance's > wave if they were to share wavelet objects via the datastore or > something. > > On Nov 17, 2:54 pm, Adam Ness wrote: >> Digging in to the Java API, it looks like the way a robot lifecycle >> goes is this: >> >> 1) A change to a wave in which the robot is a participant occurs (one >> of the several events). The wave server initiates an HTTP request to >> the robot servlet endpoint. >> 2) The servlet recieves the event notification and deserializes it >> into some objects >> 3) The servlet performs some processing on those objects, and >> generates some change objects which it attaches to the event object >> 4) The changes object is serialized into JSON, and that JSON is sent >> as the response to the HTTP request from step 1. >> 4) The wave server implements those changes into the Wave >> >> It appears that all communications with the Wave Server comes through >> these requests and responses, so there's no way to "push" data to >> google's wave federation server outside of as a response to an >> incoming event. Perhaps the python api works differently, though I >> don't understand python well enough to dig through the code and verify >> that. >> >> To push new data to the wave server would require a fundamental change >> to the way that Robots operate. I think that if this is the kind of >> functionality you're looking for, you might be better off implementing >> a custom federation server, which can serve up its own messages. I'd >> need to dig into that protocol to know for certain though, but my >> basic conception of how such an architecture could work: >> >> 1) External event triggers a wave created on your custom federated server >> 2) The federated server creates a wave, and adds you as a participant >> on the wave. >> 3) You being added as a participant causes your server to establish an >> XMPP connection to wave.google.com and notify it of the existence of >> the wave >> 4) wave.google.com and your federated server continue to exchange >> change notifications as they keep the wave in sync >> 5) The wave appears in your wave.google.com inbox >> >> Of course, wave.google.com could be substituted with any server which >> provides mailboxes (waveboxes?) for users. >> >> >> >> On Tue, Nov 17, 2009 at 11:12 AM, Olreich wrote: >> > That is true, the only way to get the Robot to access waves would be >> > to have it added and to have all of the Wavelets saved using a >> > persistence method (so that you can re-deploy without losing all >> > access to them). This would give you access to all of the waves that >> > the robot is added to >> >> > Though with the Parent/Child relationships being so
Re: [Google Wave APIs] Re: Moving waves into folders with API
Odd, the behavior must have changed, when I was working with it a week ago, It wasn't creating new wavelets, but I was actually using RootMessageBundle.createWavelet(participants), so maybe they're not the same. It definitely points to an issue with the documentation, it should be clearly spelled out which one is intended to do which, since right now they look like wrappers and convenience functions. Regardless, I agree that there should be some way to filter and arrange waves in folders, but I don't think that Robots or Gadgets are the right way to do that. There needs to be some sort of filtering mechanism a-la GMail, or possibly some "client API" that allows you to add extensions inside your client that can do things on your behalf. The problem is that Robots and Gadgets both are bound to waves, not to a user, and thus they affect everyone reading that wave, not just the user who's interested in them. As you pointed out in another thread, robots can currently do some nasty stuff to waves, I would hate to give them that kind of power over my account. Also, consider that in the greater "ecosystem" of the wave architecture, there may be other federation servers that support robots and gadgets, but might not support the same client API, or might not support clients at all. On Tue, Nov 17, 2009 at 11:00 AM, Olreich wrote: > Have you tried it recently? Because every time I use it it creates a > new wave. And I try it again...and it still creates a new wave. The > Python version might create a new wavelet inside of the wave like it's > supposed to, but the Java API most certainly creates a new wave. > > To clarify, I was speaking of having an extension do it, or having a > robot that could do it only on the waves that it created. Possibly, > not at all doing it without my express permission, with a dialog > *shudders* box or at least an opt-in button somewhere on the creation > wave. I agree, this is probably the territory of an extension, but I > want SOMETHING to take my tags and use them to organize my folders. In > fact, I would be most delighted to have a filter system like what > Gmail has (which was also mentioned above). > > I do agree that a Robot getting access to all my waves from a single > wave would be very bad, but having a robot organize the waves that > it's in (which should only be application waves) could be very good, > assuming that there's some kind of accountability for it, as malicious > persons would have a heyday with creating folders for the heck of it, > and Robot viruses I do not like. > > On Nov 17, 10:14 am, Adam Ness wrote: >> Also, wavelet.createWavelet(participants, dataDocumentCallback); in >> java doesn't create a new wave, it only creates a new wavelet inside >> an existing wave. >> >> Adam Ness >> >> >> >> On Tue, Nov 17, 2009 at 12:52 AM, Olreich wrote: >> > I agree with almost everything you said. Just one quick point on the >> > Robot's creating waves: >> >> > wavelet.createWavelet(participants, dataDocumentCallback); in Java >> >> > or >> >> > robot_abstract.NewWave(context, participants) in Python >> >> > It is possible, as Robots are indeed full participants in the system >> > as if they were their own user. >> >> > For the folder functionality, I would indeed want either a robot or an >> > extension organizing my folders, so that I can have an application >> > generate waves, and then automatically have them flow into a certain >> > folder. This makes me think of filters in Gmail, which could indeed >> > manage everything that I would want as far as folders are concerned, >> > especially if robots can add tags which will then be foisted into >> > folders by my filter settings. >> >> > On Nov 17, 2:30 am, Adam Ness wrote: >> >> Actually, there's no way in the current Robot API to create a wave. >> >> Robots can only respond to new blips on an existing wave. >> >> >> Also, because the robots operate within waves, allowing Robots to >> >> assign waves to folders is problematic, because it's not clear which >> >> user's folders receive the wave. If you've got 10 users on a wave, >> >> and a robot gets added, and some of the users have a folder, and >> >> others don't, what happens? >> >> >> Robots aren't extensions, they're just participants, AI's or Agents >> >> that act the same way that any other participant in the wave could, >> >> but automatically, and without human intervention. Just like I can't >> >> drag one of
Re: [Google Wave APIs] Re: Programmatically creating waves, was: Will other panel's functionality be exposed?
Digging in to the Java API, it looks like the way a robot lifecycle goes is this: 1) A change to a wave in which the robot is a participant occurs (one of the several events). The wave server initiates an HTTP request to the robot servlet endpoint. 2) The servlet recieves the event notification and deserializes it into some objects 3) The servlet performs some processing on those objects, and generates some change objects which it attaches to the event object 4) The changes object is serialized into JSON, and that JSON is sent as the response to the HTTP request from step 1. 4) The wave server implements those changes into the Wave It appears that all communications with the Wave Server comes through these requests and responses, so there's no way to "push" data to google's wave federation server outside of as a response to an incoming event. Perhaps the python api works differently, though I don't understand python well enough to dig through the code and verify that. To push new data to the wave server would require a fundamental change to the way that Robots operate. I think that if this is the kind of functionality you're looking for, you might be better off implementing a custom federation server, which can serve up its own messages. I'd need to dig into that protocol to know for certain though, but my basic conception of how such an architecture could work: 1) External event triggers a wave created on your custom federated server 2) The federated server creates a wave, and adds you as a participant on the wave. 3) You being added as a participant causes your server to establish an XMPP connection to wave.google.com and notify it of the existence of the wave 4) wave.google.com and your federated server continue to exchange change notifications as they keep the wave in sync 5) The wave appears in your wave.google.com inbox Of course, wave.google.com could be substituted with any server which provides mailboxes (waveboxes?) for users. On Tue, Nov 17, 2009 at 11:12 AM, Olreich wrote: > That is true, the only way to get the Robot to access waves would be > to have it added and to have all of the Wavelets saved using a > persistence method (so that you can re-deploy without losing all > access to them). This would give you access to all of the waves that > the robot is added to > > Though with the Parent/Child relationships being so wonky right now, > one still doesn't have the ability to walk around the blip tree with > any sufficient ability. Bugs have been filed for all of the Parent/ > Child relationship stuff, so that's part of the wait. > > As for Adam's solution, it looks much cleaner than mine, though I'm > not sure how instantaneous that would be. > > On Nov 17, 1:59 pm, Adam Ness wrote: >> Another way to pipe information into the robot would be using REST >> calls, since the robot is actually sitting at an HTTP endpoint on the >> appspot servers. This would be significantly easier than opening up a >> TCP Socket. Alternately, you could set up another servlet on the >> appspot server that put instructions into the appspot datastore, and >> had the Robot respond to them (potentially using polling with your >> "wait") solution. >> >> I don't believe that a robot in this context would have access to any >> waves though, since it wouldn't have a "context" to execute against. >> >> Adam Ness >> >> >> >> On Tue, Nov 17, 2009 at 10:51 AM, Olreich wrote: >> > The API calls that we listed are indeed for creating new waves, not >> > wavelets, as this does not allow for those inline "private reply" type >> > wavelets that users can create (which there is still no functionality >> > in the API to do). Robot's are indeed meant to respond to events, and >> > have no ability to create unique handlers or randomly push data down >> > to the servers without a time-based loop that runs continuously and >> > adds tons of CPU time to the robot, which may be thwarted with the >> > "wait(ms)" function available to Java Robots at least. >> >> > As for the idea that one can push data from an external data source to >> > a robot, this may be able to function with Sockets, with a robot being >> > one end of the socket, and your external service being the other. To >> > make it create waves and such, you may be able to merely add the >> > Google Wave Robot API to the project and somehow get your hands on a >> > wavelet, such as with the wasSelfAdded()[java] event. That would also >> > be the time to spawn an open server connection. Then, if the external >> > program has something to tell the Robot, it sends it
Re: [Google Wave APIs] Re: Programmatically creating waves, was: Will other panel's functionality be exposed?
Another way to pipe information into the robot would be using REST calls, since the robot is actually sitting at an HTTP endpoint on the appspot servers. This would be significantly easier than opening up a TCP Socket. Alternately, you could set up another servlet on the appspot server that put instructions into the appspot datastore, and had the Robot respond to them (potentially using polling with your "wait") solution. I don't believe that a robot in this context would have access to any waves though, since it wouldn't have a "context" to execute against. Adam Ness On Tue, Nov 17, 2009 at 10:51 AM, Olreich wrote: > The API calls that we listed are indeed for creating new waves, not > wavelets, as this does not allow for those inline "private reply" type > wavelets that users can create (which there is still no functionality > in the API to do). Robot's are indeed meant to respond to events, and > have no ability to create unique handlers or randomly push data down > to the servers without a time-based loop that runs continuously and > adds tons of CPU time to the robot, which may be thwarted with the > "wait(ms)" function available to Java Robots at least. > > As for the idea that one can push data from an external data source to > a robot, this may be able to function with Sockets, with a robot being > one end of the socket, and your external service being the other. To > make it create waves and such, you may be able to merely add the > Google Wave Robot API to the project and somehow get your hands on a > wavelet, such as with the wasSelfAdded()[java] event. That would also > be the time to spawn an open server connection. Then, if the external > program has something to tell the Robot, it sends it over that > connection. Setting up the connection might be tricky, as I would > guess robot instances are not the easiest to find (so you'd probably > connect to the static site, save the robot address and then create the > reverse relationship). And, this all depends on how much freedom > Google AppEngine and Google Wave has given for networking. > > Pushing requests to Wave is dangerous, as there would be no > authentication. I can see Google having this be fleshed out once they > allow all Robots to participate, rather than just AppSpot Robots, but > for now, it's not safe, so they probably won't allow it until they > figure out how to make it safe. After all, Robot's have quite a bit of > power to annoy everyone, so long as they are initialized by a single > user adding them to any Wave. They can also ruin waves, lock waves, > and do all sorts of annoying things when put into a Wave that they > shouldn't be. > > On Nov 17, 8:55 am, jhouk wrote: >> Thanks Olrech and Pamela! >> >> Please forgive me if I'm being dense here, but it looks like the APIs >> you're listing are designed for creating wavelets within an existing >> wave, or spawning a new wave from an existing wave. The issue being >> that robots are--and please correct me if I'm wrong--designed to >> listen in on an existing wave and react to activity within the wave. >> What we're looking to do, on the other hand, is run services external >> to Wave, and based on external events, communicate to Google Wave that >> a new top level wave (not wavelet) needs to be created with a set of >> participants. >> >> Now, as I type this I'm thinking that I might be able to use the >> current APIs in an unorthodox way to get this functionality. Perhaps >> I can manually create a starter wave with myself and a monitor robot >> as participants to bootstrap the robot. Once it's running, the bot >> can 'pull' any new wave notifications from our external service and >> spawn new waves with the appropriate participants. >> >> Still, it seems like some kind of Google Wave listening service that >> would allow us to 'push' requests to Wave would be a more >> straightforward and efficient mechanism, but this should be enough to >> get us started. >> >> Thanks again! >> --Justin >> >> On Nov 17, 5:24 am, "pamela (Google Employee)" >> wrote: >> >> >> >> > In addition, I published some sample code here for Python wave >> > creation:http://wave-samples-gallery.appspot.com/about_app?app_id=60017 >> >> > <http://wave-samples-gallery.appspot.com/about_app?app_id=60017>- pamela >> >> > On Mon, Nov 16, 2009 at 1:48 PM, Olreich wrote: >> > > To create a wave via programming in Java: >> >> > > wavelet.createWavelet(participants, dataDocument); >> &
Re: [Google Wave APIs] Re: Moving waves into folders with API
Also, wavelet.createWavelet(participants, dataDocumentCallback); in java doesn't create a new wave, it only creates a new wavelet inside an existing wave. Adam Ness On Tue, Nov 17, 2009 at 12:52 AM, Olreich wrote: > I agree with almost everything you said. Just one quick point on the > Robot's creating waves: > > wavelet.createWavelet(participants, dataDocumentCallback); in Java > > or > > robot_abstract.NewWave(context, participants) in Python > > It is possible, as Robots are indeed full participants in the system > as if they were their own user. > > For the folder functionality, I would indeed want either a robot or an > extension organizing my folders, so that I can have an application > generate waves, and then automatically have them flow into a certain > folder. This makes me think of filters in Gmail, which could indeed > manage everything that I would want as far as folders are concerned, > especially if robots can add tags which will then be foisted into > folders by my filter settings. > > On Nov 17, 2:30 am, Adam Ness wrote: >> Actually, there's no way in the current Robot API to create a wave. >> Robots can only respond to new blips on an existing wave. >> >> Also, because the robots operate within waves, allowing Robots to >> assign waves to folders is problematic, because it's not clear which >> user's folders receive the wave. If you've got 10 users on a wave, >> and a robot gets added, and some of the users have a folder, and >> others don't, what happens? >> >> Robots aren't extensions, they're just participants, AI's or Agents >> that act the same way that any other participant in the wave could, >> but automatically, and without human intervention. Just like I can't >> drag one of your waves into one of your folders, a robot can't move a >> wave into one of your folders, because they aren't the Robot's >> folders, they're Your Folders. Giving a random robot access to my >> folders just because I happened to have opened a wave that they were >> partipating in would be a huge security hole, and I wouldn't want to >> allow that. >> >> Tags are a different matter, since they are assigned to the wave, not >> bound to a user. Neither the Java API nor the Python API appears to >> currently support adding tags to items, though it seems reasonable >> that they could. I'd be worried about robot authors misusing them, >> but it seems like something that should make it into those APIs at >> some point in the future. >> >> Gadgets are closer to the standard definition of "extensions" but >> they're still bound to the wave, not a particular user. Again, >> granting gadgets permission to muck about with my folder structure >> just because I happened to open a wave they were attached to would be >> a bad idea. This would be like allowing attachments to auto-execute >> themselves when you open an email, and any security expert can tell >> you why that's a bad idea. >> >> Again, I think a third type of "API" would be necessary to support the >> kind of extensions you're talking about here. Either of the existing >> extension APIs would cause serious security flaws if they were to be >> allowed to move things around in your folders, or create new waves. >> >> >> >> On Mon, Nov 16, 2009 at 11:08 PM, Olreich wrote: >> > The problem is that Robots can create a mass of waves, but can't >> > organize it very well for the user, so the user wouldn't want a robot >> > to do anything outside of the wave, but rather operate entirely >> > within. Allowing robots to organize themselves would be expand them >> > outside of a wave-by-wave basis and allow them to be more full- >> > featured applications. Then again, since robots are essentially >> > extensions, maybe add the functionality only in robots that are part >> > of extensions. >> >> > On Nov 17, 1:58 am, Adam Ness wrote: >> >> I don't think Robots could ever be expected to be capable of moving >> >> items into folders, since they're just another Participant on the >> >> wave, and the folders belong to other participants. >> >> >> Possibly a Gadget API would be a better place for this, or maybe a new >> >> client plugin API, to allow users to write their own plugins that >> >> don't use the protocol at all, but just the client. >> >> >> On Sun, Nov 15, 2009 at 2:07 AM, pamela (Google Employee) >> >&g
Re: [Google Wave APIs] Re: Moving waves into folders with API
But what if I read a wave which you added that gadget or robot to, and I don't want that gadget or robot to automatically manage my folders? On Tue, Nov 17, 2009 at 12:52 AM, Olreich wrote: > I agree with almost everything you said. Just one quick point on the > Robot's creating waves: > > wavelet.createWavelet(participants, dataDocumentCallback); in Java > > or > > robot_abstract.NewWave(context, participants) in Python > > It is possible, as Robots are indeed full participants in the system > as if they were their own user. > > For the folder functionality, I would indeed want either a robot or an > extension organizing my folders, so that I can have an application > generate waves, and then automatically have them flow into a certain > folder. This makes me think of filters in Gmail, which could indeed > manage everything that I would want as far as folders are concerned, > especially if robots can add tags which will then be foisted into > folders by my filter settings. > > On Nov 17, 2:30 am, Adam Ness wrote: >> Actually, there's no way in the current Robot API to create a wave. >> Robots can only respond to new blips on an existing wave. >> >> Also, because the robots operate within waves, allowing Robots to >> assign waves to folders is problematic, because it's not clear which >> user's folders receive the wave. If you've got 10 users on a wave, >> and a robot gets added, and some of the users have a folder, and >> others don't, what happens? >> >> Robots aren't extensions, they're just participants, AI's or Agents >> that act the same way that any other participant in the wave could, >> but automatically, and without human intervention. Just like I can't >> drag one of your waves into one of your folders, a robot can't move a >> wave into one of your folders, because they aren't the Robot's >> folders, they're Your Folders. Giving a random robot access to my >> folders just because I happened to have opened a wave that they were >> partipating in would be a huge security hole, and I wouldn't want to >> allow that. >> >> Tags are a different matter, since they are assigned to the wave, not >> bound to a user. Neither the Java API nor the Python API appears to >> currently support adding tags to items, though it seems reasonable >> that they could. I'd be worried about robot authors misusing them, >> but it seems like something that should make it into those APIs at >> some point in the future. >> >> Gadgets are closer to the standard definition of "extensions" but >> they're still bound to the wave, not a particular user. Again, >> granting gadgets permission to muck about with my folder structure >> just because I happened to open a wave they were attached to would be >> a bad idea. This would be like allowing attachments to auto-execute >> themselves when you open an email, and any security expert can tell >> you why that's a bad idea. >> >> Again, I think a third type of "API" would be necessary to support the >> kind of extensions you're talking about here. Either of the existing >> extension APIs would cause serious security flaws if they were to be >> allowed to move things around in your folders, or create new waves. >> >> >> >> On Mon, Nov 16, 2009 at 11:08 PM, Olreich wrote: >> > The problem is that Robots can create a mass of waves, but can't >> > organize it very well for the user, so the user wouldn't want a robot >> > to do anything outside of the wave, but rather operate entirely >> > within. Allowing robots to organize themselves would be expand them >> > outside of a wave-by-wave basis and allow them to be more full- >> > featured applications. Then again, since robots are essentially >> > extensions, maybe add the functionality only in robots that are part >> > of extensions. >> >> > On Nov 17, 1:58 am, Adam Ness wrote: >> >> I don't think Robots could ever be expected to be capable of moving >> >> items into folders, since they're just another Participant on the >> >> wave, and the folders belong to other participants. >> >> >> Possibly a Gadget API would be a better place for this, or maybe a new >> >> client plugin API, to allow users to write their own plugins that >> >> don't use the protocol at all, but just the client. >> >> >> On Sun, Nov 15, 2009 at 2:07 AM, pamela (Google Employee) >> >> >> wrote: >> &
Re: [Google Wave APIs] Re: Moving waves into folders with API
Actually, there's no way in the current Robot API to create a wave. Robots can only respond to new blips on an existing wave. Also, because the robots operate within waves, allowing Robots to assign waves to folders is problematic, because it's not clear which user's folders receive the wave. If you've got 10 users on a wave, and a robot gets added, and some of the users have a folder, and others don't, what happens? Robots aren't extensions, they're just participants, AI's or Agents that act the same way that any other participant in the wave could, but automatically, and without human intervention. Just like I can't drag one of your waves into one of your folders, a robot can't move a wave into one of your folders, because they aren't the Robot's folders, they're Your Folders. Giving a random robot access to my folders just because I happened to have opened a wave that they were partipating in would be a huge security hole, and I wouldn't want to allow that. Tags are a different matter, since they are assigned to the wave, not bound to a user. Neither the Java API nor the Python API appears to currently support adding tags to items, though it seems reasonable that they could. I'd be worried about robot authors misusing them, but it seems like something that should make it into those APIs at some point in the future. Gadgets are closer to the standard definition of "extensions" but they're still bound to the wave, not a particular user. Again, granting gadgets permission to muck about with my folder structure just because I happened to open a wave they were attached to would be a bad idea. This would be like allowing attachments to auto-execute themselves when you open an email, and any security expert can tell you why that's a bad idea. Again, I think a third type of "API" would be necessary to support the kind of extensions you're talking about here. Either of the existing extension APIs would cause serious security flaws if they were to be allowed to move things around in your folders, or create new waves. On Mon, Nov 16, 2009 at 11:08 PM, Olreich wrote: > The problem is that Robots can create a mass of waves, but can't > organize it very well for the user, so the user wouldn't want a robot > to do anything outside of the wave, but rather operate entirely > within. Allowing robots to organize themselves would be expand them > outside of a wave-by-wave basis and allow them to be more full- > featured applications. Then again, since robots are essentially > extensions, maybe add the functionality only in robots that are part > of extensions. > > On Nov 17, 1:58 am, Adam Ness wrote: >> I don't think Robots could ever be expected to be capable of moving >> items into folders, since they're just another Participant on the >> wave, and the folders belong to other participants. >> >> Possibly a Gadget API would be a better place for this, or maybe a new >> client plugin API, to allow users to write their own plugins that >> don't use the protocol at all, but just the client. >> >> On Sun, Nov 15, 2009 at 2:07 AM, pamela (Google Employee) >> >> >> >> wrote: >> > Hi jhb - >> > A wave can only be in one folder, and robots do not currently have the >> > ability to move wave into a folder (or assign tags, a related action). >> > Please file a feature request for folder manipulation here: >> >http://code.google.com/p/google-wave-resources/issues/entry?template=... >> > - pamela >> >> > On Fri, Nov 13, 2009 at 11:30 PM, jhb wrote: >> >> >> Is there a way to manipulate the location of a wave from a user's >> >> inbox to robot created or previously created folders. Also, can a >> >> wave be in multiple folders? >> >> >> -- >> >> >> You received this message because you are subscribed to the Google Groups >> >> "Google Wave API" group. >> >> To post to this group, send email to google-wave-...@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> google-wave-api+unsubscr...@googlegroups.com. >> >> For more options, visit this group at >> >>http://groups.google.com/group/google-wave-api?hl=. >> >> > -- >> >> > You received this message because you are subscribed to the Google Groups >> > "Google Wave API" group. >> > To post to this group, send email to google-wave-...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > google-wave-api+unsubscr...@googlegroups.com. >> > For more options, visit this gr
Re: [Google Wave APIs] Moving waves into folders with API
I don't think Robots could ever be expected to be capable of moving items into folders, since they're just another Participant on the wave, and the folders belong to other participants. Possibly a Gadget API would be a better place for this, or maybe a new client plugin API, to allow users to write their own plugins that don't use the protocol at all, but just the client. On Sun, Nov 15, 2009 at 2:07 AM, pamela (Google Employee) wrote: > Hi jhb - > A wave can only be in one folder, and robots do not currently have the > ability to move wave into a folder (or assign tags, a related action). > Please file a feature request for folder manipulation here: > http://code.google.com/p/google-wave-resources/issues/entry?template=Robots%20Feature%20Request > - pamela > > On Fri, Nov 13, 2009 at 11:30 PM, jhb wrote: >> >> Is there a way to manipulate the location of a wave from a user's >> inbox to robot created or previously created folders. Also, can a >> wave be in multiple folders? >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Google Wave API" group. >> To post to this group, send email to google-wave-...@googlegroups.com. >> To unsubscribe from this group, send email to >> google-wave-api+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-wave-api?hl=. >> >> > > -- > > You received this message because you are subscribed to the Google Groups > "Google Wave API" group. > To post to this group, send email to google-wave-...@googlegroups.com. > To unsubscribe from this group, send email to > google-wave-api+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-wave-api?hl=. > -- You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to google-wave-...@googlegroups.com. To unsubscribe from this group, send email to google-wave-api+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=.
Re: [Google Wave APIs] Re: gadget state unavailable in onload handler
I believe that the "document.onload" and the standard jQuery
$(function(){}) methods don't work correctly in wave due to the odd
loading ordrer. Instead, use
function init() {
if( typeof wave!='undefined' && wave.isInWaveContainer() ) {
// do your wave-specific initialization here
}
}
gadgets.util.registerOnLoadHandler(init);
On Mon, Nov 16, 2009 at 8:07 AM, qMax wrote:
> Ok.
> I believe in magic.
> But this time i cannot figure out what exact magic is necessary.
>
> Here is minimal gadget, containing only debug log and printing state/
> mode/viewer/host at various stages:
> http://qmax.academ.org/wave/test.xml
>
> At start of onloadHandler there is:
> if (wave === undefined || ! wave.isInWaveContainer()) {
> alert('I wanna be in a wave!');
> return;
> }
>
> Here is instance of it:
> https://wave.google.com/a/wavesandbox.com/#restored:wave:wavesandbox.com!w%252BW80qIMN-A.4
>
> After gadget loaded it shows that state/viewer/host/mode are null (but
> not undefined).
>
> After gadget loaded, stateUpdated automatically triggered to setup the
> state.
> (Chrome 4.0.223.11, Firefox 3.5.3)
>
> What's wrong with it?
>
> On 16 ноя, 20:56, "\\x00" wrote:
>> http://groups.google.com/group/google-wave-api/browse_thread/thread/f...
>>
>> I don't use
>>
>> Just put
>>
>> if (typeof wave != 'undefined' && wave.isInWaveContainer()){
>> wave.setStateCallback(stateUpdated);
>> wave.getState()
>> gadgets.window.adjustHeight();
>> }
>>
>> at the end of my jquery document ready works fine
>>
>> On Nov 15, 7:50 pm, qMax wrote:
>>
>>
>>
>> > Hi.
>>
>> > I discovered that gadget state is unavailable in onLoad handler,
>> > even if it exists in blip when wave is opened.
>> > The same for viewer and host.
>>
>> > Is it bug or feature?
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Google Wave API" group.
> To post to this group, send email to google-wave-...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-wave-api+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-wave-api?hl=.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Google Wave API" group.
To post to this group, send email to google-wave-...@googlegroups.com.
To unsubscribe from this group, send email to
google-wave-api+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-wave-api?hl=.
