I'm not attacking the idea at all. Like I said, I'm working on the same thing, so I'd love to hear your ideas on some of these.
On Mon, Nov 9, 2009 at 11:05 AM, Christopher Baker <[email protected]>wrote: > 2. Use a gadget that goes with the robot (can the robot add it?) that you > can fill in information (maybe even store a cookie for next time). > This sounds reasonable, but what would happen to the credentials? Where do they get stored? How would you associate those credentials with the content you mean to publish? Assuming you're abandoning OAuth for a moment, and prefer to deal directly with usernames and passwords, that information starts out in the gadget. You'd presumably post that to your robot (as a regular HTTP request, not via the wave), but the wave's content would not accompany that. Your robot would still need to connect, somehow, the content that it's receiving events for, and the credentials gathered by the gadget. The wave ID would seem to be the logical way to do that, but you still have to authenticate the event itself somehow. > 3. 2 would contain this information (URL, user, pass, title=subject). My > thoughts would be to add robot as first participant, have robot store info > then clear gadget to protect info before adding more participants. > You can't enforce that the robot be the first participant. What should happen if the robot is not the first participant? What if it's an unrelated person adding the robot? If you create a gadget to get the user to authenticate, and to decide where to send the content, what happens when someone else fills in the form and submits it before you get a chance to? Should both attempts to publish the wave succeed? (I'd say yes, and that this would be a feature.) If not, how does the owner of a wave recover from that situation? > 4. To fake events, they need your password. > Robot events are wholly independent of the gadget. The gadget does not see changes to the content, and cannot provide those changes to the robot along with authentication credentials. The best you can do is have the gadget provide the credentials to the robot, and have the robot independently receive and act upon the events, somehow connecting the event to the credentials stored earlier. The problem is that if I know your wave ID, I can forge events to your robot and convince your robot that changes are being made to a wave. You can't store authentication credentials in the wave itself, because anyone can see that. You might be able to have the gadget+robot generate some sort of authentication token, and have the gadget store *that* in the wave, and use that as your authenticator when the robot receives events saying that some content has been changed. I haven't thought through this very well yet, though. The issue of authenticating wave events is IMO a serious problem that precludes this type of robot, except for personal/experimental use. 6. If somebody besides the wave creator (stored by the robot) tries to edit > the main wavelet, the robot does not publish the result and resets the > content to the last published. > I'd argue that it would be *desirable* to allow other participants in the wave to have the ability to make changes to the content. Consider the case of a collaborative blog. The ACLs that have been promised as forthcoming in wave might make this easier to do (allow people to add comments without allowing them to modify the original document). David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en -~----------~----~----~----~------~----~------~--~---
