Apologies if this has been asked before, but I can't find any info on
it...
Embedding waves in a blog looked pretty cool, but my impression (based
on nothing but the video of the I/O demo) is that it's all Javascript-
based. This makes me wonder whether Search Engines would be able to
read any content embedded in a blog this way? Is there a server-side
embed API that would allow the current wave to be output in a way
search engines can index it?
This is purely guesswork but given that waves are extensively client-
side driven, and that the current push model can not physically push
contents onto static resource (IE: stream/poll aren't natively
implemented), it's most likely going to be a no (unless the crawlers
can parse javascript). However, it's possible to poll the resources on
the serverside and render it in a indexable, non-realtime fashion to
the client, however that defeats the purpose of wave.
Of course, my knowledge is limited so it might be better for one of
the brilliant google employee to delve further into this problem. I
don't know, Google's been known to come up with solutions to ideas
traditionally thought to be impossible to implement (taking wave for
example)
On Nov 7, 6:30 pm, Danny Tuppeny <m...@dantup.me.uk> wrote:
> Apologies if this has been asked before, but I can't find any info on
> it...
> Embedding waves in a blog looked pretty cool, but my impression (based
> on nothing but the video of the I/O demo) is that it's all Javascript-
> based. This makes me wonder whether Search Engines would be able to
> read any content embedded in a blog this way? Is there a server-side
> embed API that would allow the current wave to be output in a way
> search engines can index it?
Personally, I think that the blogs with waves embedded in them look rather
funny, even with matching colors. I would think that the best option would
be to create a robot that updates the blog based on the wave content. I plan
on finding out if anybody has done this, or doing it myself, although I have
not had the time to do this. Perhaps there's even a simple way? =]
On Sun, Nov 8, 2009 at 6:53 PM, Lee <leeyuan...@gmail.com> wrote:
> This is purely guesswork but given that waves are extensively client-
> side driven, and that the current push model can not physically push
> contents onto static resource (IE: stream/poll aren't natively
> implemented), it's most likely going to be a no (unless the crawlers
> can parse javascript). However, it's possible to poll the resources on
> the serverside and render it in a indexable, non-realtime fashion to
> the client, however that defeats the purpose of wave.
> Of course, my knowledge is limited so it might be better for one of
> the brilliant google employee to delve further into this problem. I
> don't know, Google's been known to come up with solutions to ideas
> traditionally thought to be impossible to implement (taking wave for
> example)
> On Nov 7, 6:30 pm, Danny Tuppeny <m...@dantup.me.uk> wrote:
> > Apologies if this has been asked before, but I can't find any info on
> > it...
> > Embedding waves in a blog looked pretty cool, but my impression (based
> > on nothing but the video of the I/O demo) is that it's all Javascript-
> > based. This makes me wonder whether Search Engines would be able to
> > read any content embedded in a blog this way? Is there a server-side
> > embed API that would allow the current wave to be output in a way
> > search engines can index it?
On Sun, Nov 8, 2009 at 11:52 PM, Christopher Baker <slithyto...@gmail.com>wrote:
> Personally, I think that the blogs with waves embedded in them look rather > funny, even with matching colors. I would think that the best option would > be to create a robot that updates the blog based on the wave content. I plan > on finding out if anybody has done this, or doing it myself, although I have > not had the time to do this. Perhaps there's even a simple way? =]
I'm playing with doing this. Unfortunately it's not straightforward, and at least two Wave bugs preclude a well-designed solution, IMO. There are several issues I'm thinking of ways around:
1. Serializing the blip to HTML. It's easy enough to generate <p> and <br> elements to get the structure of the blip, but what about overlapping annotations? Embedded gadgets? Images[1]?
2. How does the robot authenticate to the place you'll store the content? Bloggy solves this by hosting the content locally. This pretty much requires something like OAuth. If the target for your content doesn't support that, that may mean more work implementing it.
3. When you add the robot to the wave, how does the robot know where to send the content? What if multiple people want to use the same robot to post to separate places? More UI/configuration needed.
4. How does the robot know that the events it's receiving from Wave are legitimate[2]? You don't want someone sending fake events that cause the robot to publish something it's not supposed to.
1. I haven't look closely enough to solve this bit just yet.
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).
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.
4. To fake events, they need your password.
5. Of course. The post is created and editted in a single (i believe
the proper term is wavelet). When people that you add to the wave
reply, these are the comments. When a non wave user replies on the
site, the robot creates a wavelet for that person.
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.
7. Yes, this would require custom software, but I can help with this.
Christopher Baker
On Nov 9, 2009, at 8:22 AM, David Nesting <da...@fastolfe.net> wrote:
> On Sun, Nov 8, 2009 at 11:52 PM, Christopher Baker <slithyto...@gmail.com > > wrote:
> Personally, I think that the blogs with waves embedded in them look
> rather funny, even with matching colors. I would think that the best
> option would be to create a robot that updates the blog based on the
> wave content. I plan on finding out if anybody has done this, or
> doing it myself, although I have not had the time to do this.
> Perhaps there's even a simple way? =]
> I'm playing with doing this. Unfortunately it's not
> straightforward, and at least two Wave bugs preclude a well-designed
> solution, IMO. There are several issues I'm thinking of ways around:
> 1. Serializing the blip to HTML. It's easy enough to generate <p>
> and <br> elements to get the structure of the blip, but what about
> overlapping annotations? Embedded gadgets? Images[1]?
> 2. How does the robot authenticate to the place you'll store the
> content? Bloggy solves this by hosting the content locally. This
> pretty much requires something like OAuth. If the target for your
> content doesn't support that, that may mean more work implementing it.
> 3. When you add the robot to the wave, how does the robot know where
> to send the content? What if multiple people want to use the same
> robot to post to separate places? More UI/configuration needed.
> 4. How does the robot know that the events it's receiving from Wave
> are legitimate[2]? You don't want someone sending fake events that
> cause the robot to publish something it's not supposed to.
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).
I apologize if I made it look like you were attacking the idea.
I haven't yet had time to get into wave development. I know nothing at all
about OAuth.
I guess it would make sense to create the post (collaboratively or
otherwise) before adding the robot. Perhaps the gadget could be inserted in
a private wavelet to the robot, thereby removing the storage requirements
for the credentials (my original idea would have been to receive some sort
of key from the blog server based on the credentials [nobody would ever have
access to this except the robot] and store that [to prevent security issues
of storing actual credentials], in some sort of robot-only database along
with the waveid, and send it with requests to the blog server.)
As for collaborative blogging, I hadn't thought about this. In this case,
all non-editor comments would be made from the blog site, (and the robot
would create the appropriate wavelets). Perhaps this could be based on
whether the gadget is in a private wavelet to the robot or a public one.
(can the robot tell who is privy to a private wavelet?) (and can the viewers
of a private wavelet be changed at a later point if somebody is abusing
their edit rights?)
As for authenticating wave events, the key mentioned above could be stored
in the gadget (which would only be exposed to the individuals who have edit
rights). If this key is intercepted by a 3rd party, it would be equivalent
of user/pass being intercepted on a login form. The correct key must match
up with the correct waveid in the robots database in order for the result to
be pushed. (perhaps the robot would create an alert wavelet when it receives
a call that doesn't match)
The gadget would also probably need some sort of control panel (to add the
robot, but not publish yet, or to pause publishing of main post while others
check the changes or something of the sort).
Christopher
Also, should be move our discussion to a wave to reduce traffic here?
anybody object to our discussions in here?
On Mon, Nov 9, 2009 at 2: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).
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).
|
