It seems reasonable to me, that you could have a robot which is tailored specifically to certain websites (programmable @ user end), in fact an app that spawns robots, which, before "fully creating" them, the user has to input website interactivity details first.
i.e. User1 spawns Robot1: input1:URL input2:username input3:password input4:purpose (nesting etc.) Robot1 becomes available to publish the information from the wave to the website accordingly by obtaining specific user credentials. On Nov 9, 5:43 pm, David Nesting <da...@fastolfe.net> wrote: > 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 > <slithyto...@gmail.com>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 google-wave-api@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 -~----------~----~----~----~------~----~------~--~---
