What is a browser in a web hook world?
250 views
Skip to first unread message
deostroll
Jul 30, 2009, 2:38:08 PM7/30/09
to Web Hooks
Is this web hook thing meant to be a server-to-server based
communication thing or a server-to-client based thing? I just don't
see how client browser/applications fit into the picture...
--deostroll
communication thing or a server-to-client based thing? I just don't
see how client browser/applications fit into the picture...
--deostroll
Jeff Lindsay
Jul 31, 2009, 4:52:38 PM7/31/09
to webh...@googlegroups.com
Server/client distinction will increasingly become effectively
meaningless. Webhooks are for server-to-server. Yes, some people talk
about putting a server in the browser. No, I don't think that will
take off. Stuff that actually needs to go the last mile to the client
behind the firewall/NAT/whatever can use XMPP. But I really see little
reason for webhooks to involve the browser/client ... **however** that
in no way means they will not disrupt the client/browser experience...
in fact, I believe they will do a lot for it, just indirectly. See
initial statement. :P
--
Jeff Lindsay
http://webhooks.org -- Make the web more programmable
http://shdh.org -- A party for hackers and thinkers
http://tigdb.com -- Discover indie games
http://progrium.com -- More interesting things
meaningless. Webhooks are for server-to-server. Yes, some people talk
about putting a server in the browser. No, I don't think that will
take off. Stuff that actually needs to go the last mile to the client
behind the firewall/NAT/whatever can use XMPP. But I really see little
reason for webhooks to involve the browser/client ... **however** that
in no way means they will not disrupt the client/browser experience...
in fact, I believe they will do a lot for it, just indirectly. See
initial statement. :P
Jeff Lindsay
http://webhooks.org -- Make the web more programmable
http://shdh.org -- A party for hackers and thinkers
http://tigdb.com -- Discover indie games
http://progrium.com -- More interesting things
Tony Garnock-Jones
Aug 1, 2009, 1:03:31 PM8/1/09
to webh...@googlegroups.com
Hi Jeff,
While I agree with you that the server/client distinction will start to become meaningless, I think webhooks-to-the-client has more potential than you suggest.
I like thinking about HTTP POST based messaging (e.g. PubSubHubBub) as a good example of why it would be useful. "Last-mile" apps can use XMPP [1], but if you could use a single application protocol, with the same semantics, all the way from edge to core to edge of the network again, wouldn't you want to?
To sketch an example: the reversehttp PubSubHubBub endpoint demo [2] (that currently just displays the posts it receives) could be fleshed out into a google-reader-like low-latency feed reader, with the PSHB hub directly forwarding fresh content to the web page's own exposed webhook target URL. The whole app would stay in HTTP-land, and besides the generic reversehttp reflector, no server-side machinery would be needed at all.
I am, of course, biased ;-) , but to me having a single generic protocol for participating bidirectionally in the HTTP ecosystem beats each app developer repetitively building ad-hoc solutions to the "last-mile" problem every time there is one.
Regards,
Tony
[1]: although browsers don't support XMPP natively either, so some kind of shim has to be put in place for that to work
[2]: http://www.reversehttp.net/demos/endpoint.html
While I agree with you that the server/client distinction will start to become meaningless, I think webhooks-to-the-client has more potential than you suggest.
2009/7/31 Jeff Lindsay <prog...@gmail.com>
Stuff that actually needs to go the last mile to the client
behind the firewall/NAT/whatever can use XMPP. But I really see little
reason for webhooks to involve the browser/client ...
I like thinking about HTTP POST based messaging (e.g. PubSubHubBub) as a good example of why it would be useful. "Last-mile" apps can use XMPP [1], but if you could use a single application protocol, with the same semantics, all the way from edge to core to edge of the network again, wouldn't you want to?
To sketch an example: the reversehttp PubSubHubBub endpoint demo [2] (that currently just displays the posts it receives) could be fleshed out into a google-reader-like low-latency feed reader, with the PSHB hub directly forwarding fresh content to the web page's own exposed webhook target URL. The whole app would stay in HTTP-land, and besides the generic reversehttp reflector, no server-side machinery would be needed at all.
I am, of course, biased ;-) , but to me having a single generic protocol for participating bidirectionally in the HTTP ecosystem beats each app developer repetitively building ad-hoc solutions to the "last-mile" problem every time there is one.
Regards,
Tony
[1]: although browsers don't support XMPP natively either, so some kind of shim has to be put in place for that to work
[2]: http://www.reversehttp.net/demos/endpoint.html
Jeff Lindsay
Aug 1, 2009, 1:17:10 PM8/1/09
to webh...@googlegroups.com
> While I agree with you that the server/client distinction will start to
> become meaningless, I think webhooks-to-the-client has more potential than
> you suggest.
> become meaningless, I think webhooks-to-the-client has more potential than
> you suggest.
I would love to be convinced. I guess the primary advantage is having
direct communication with local apps? What are some great use-cases
for webhooks-to-the-client?
> I like thinking about HTTP POST based messaging (e.g. PubSubHubBub) as a
> good example of why it would be useful. "Last-mile" apps can use XMPP [1],
> but if you could use a single application protocol, with the same semantics,
> all the way from edge to core to edge of the network again, wouldn't you
> want to?
Sure ... and it's roughly the same amount of work to implement reverse
HTTP and XMPP on the client ... but really, I think it will have
trouble being adopted because reverse HTTP is a bit harder to grok
than XMPP conceptually (part of the reason people want to think of
XMPP when presented with the idea of webhooks for the first time).
Plus, while I think these features will find their way to
HTTP/webhooks, things like presence are very useful for non-persistent
client nodes.
> I am, of course, biased ;-) , but to me having a single generic protocol for
> participating bidirectionally in the HTTP ecosystem beats each app developer
> repetitively building ad-hoc solutions to the "last-mile" problem every time
> there is one.
Well if we're talking about an ideal scenario (and I love idealized
design), we could just have IPv6 everywhere and reverse HTTP wouldn't
be necessary. :)
deostroll
Aug 1, 2009, 2:26:00 PM8/1/09
to WebHooks
How would this concept help, say, twitter?
--deostroll
--deostroll
Jeff Lindsay
Aug 1, 2009, 3:07:46 PM8/1/09
to webh...@googlegroups.com
Twitter would benefit by expanding their ecosystem by lowering the
barrier to entry in making extensions to Twitter. They currently have
a stream API which lets you do some of the things you can do if they
had webhooks, however it's a little bit difficult to use. I've built a
wrapper around their stream API to provide webhooks
(twitterhooks.com).
For users, it would open up a new level of programmability. If you had
hooks for when users follow you, either you could write a script that
would determine whether they're worth following back, or worth
blocking. Maybe you want to send them a message before following them
back. If you don't want to or know how to throw together a simple
script that could do this, third party services would likely emerge to
do this for you.
One of the use cases for webhooks is notifications ... having code
hooked up to events means you can deliver the notification however you
like. For example, Twitter has direct messaging that they have
hardcoded the options of delivering via email or SMS (as well as
through the website). If they had a webhook for direct messages, you
could deliver the message via IM or even telephone (see Twilio). You
could filter messages however you like. You could write
auto-responders.
Anyway, these are just some examples. Some are things you can't do now
at all. Some are examples of things you can do now, but are difficult
or inaccessible. But I think Twitter is a good example to think
around.
They were, btw, one of the first companies that told me they wanted to
do webhooks (meaning, they saw the value in them) ... but never did
for various reasons.
On Sat, Aug 1, 2009 at 11:26 AM, deostroll<deos...@gmail.com> wrote:
>
> How would this concept help, say, twitter?
> --deostroll
> >
>
barrier to entry in making extensions to Twitter. They currently have
a stream API which lets you do some of the things you can do if they
had webhooks, however it's a little bit difficult to use. I've built a
wrapper around their stream API to provide webhooks
(twitterhooks.com).
For users, it would open up a new level of programmability. If you had
hooks for when users follow you, either you could write a script that
would determine whether they're worth following back, or worth
blocking. Maybe you want to send them a message before following them
back. If you don't want to or know how to throw together a simple
script that could do this, third party services would likely emerge to
do this for you.
One of the use cases for webhooks is notifications ... having code
hooked up to events means you can deliver the notification however you
like. For example, Twitter has direct messaging that they have
hardcoded the options of delivering via email or SMS (as well as
through the website). If they had a webhook for direct messages, you
could deliver the message via IM or even telephone (see Twilio). You
could filter messages however you like. You could write
auto-responders.
Anyway, these are just some examples. Some are things you can't do now
at all. Some are examples of things you can do now, but are difficult
or inaccessible. But I think Twitter is a good example to think
around.
They were, btw, one of the first companies that told me they wanted to
do webhooks (meaning, they saw the value in them) ... but never did
for various reasons.
On Sat, Aug 1, 2009 at 11:26 AM, deostroll<deos...@gmail.com> wrote:
>
> How would this concept help, say, twitter?
> --deostroll
> >
>
Hedge Hog
Aug 1, 2009, 8:57:47 PM8/1/09
to webh...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Aug 2, 2009 at 3:17 AM, Jeff Lindsay wrote:
>
>> While I agree with you that the server/client distinction will start to
>> become meaningless, I think webhooks-to-the-client has more potential than
>> you suggest.
>
Hi,
I had Tony's same thoughts:
>> I am, of course, biased ;-) , but to me having a single generic protocol for
>> participating bidirectionally in the HTTP ecosystem beats each app developer
>> repetitively building ad-hoc solutions to the "last-mile" problem every time
>> there is one.
Perhaps it is no accident that I had the Ruby ReverseHTTP firewall
tunnel example in mind.
Jeff asks:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.8)
iEYEARECAAYFAkp05IoACgkQL/DTCig+Nhco8ACfRrCdUiz6avgTctqGIIMmWJrF
dgYAn0SIOAslXsE/TTmBjkDJKYGgEK54
=HFt4
-----END PGP SIGNATURE-----
> I would love to be convinced. I guess the primary advantage is having
> direct communication with local apps? What are some great use-cases
> for webhooks-to-the-client?
Here is an interesting 'real-world' example that could possibly use
web hooks in a way Tony suggests.
http://www.fileguru.com/Reverse-HTTP-Starter/info
The purpose of the link is to show that it does seem people use things
in wierd, wonderful and possibly even non-optimal ways.
I'd go further and observe that this is the 'problem' IT gurus have to
live with, the result of allowing people without formal comp.sci.
training to own computers/pdas/phones and have easy network
connectivity... they learn to solve a problem (even ones that don't
exist) overtime, by iteration/tiral-and-error and in a ways that can
resemble a random walk.
The only observation I'd like you to seriously consider is: please
don't /only/ think about webhooks in terms of having a large global
provider (google, etc.), or even in terms of a middle-man/hub
mediating between several providers.
I think there can be legitimate, and to the users, very important,
peer-to-peer use cases.... people know when their computers are on -
they are on when they are using them :)
These are use cases that people might be too shy/embarassed to promote
because they know they are out of their depth (in comp. sci. terms)
and they know they have only manged to cobble something together that
'just' works....
I suppose my point is webhooks offers an interesting way for people to
hook together the work they do on their computers/pdas/phones - all
without a middle man in sight.
In this respect I think Tony's observations are important.
Further more I think ideal-world/technically-correct counter points
don't make people's real-world-needs go away, nor will they stop all
those pesky users employ computers in ways that they weren't supposed
to - I'm not saying you shouldn't feel free to write to your
congressional rep about it ;)
Yes, no doubt some individuals will use a solution not knowning ipv6,
or whatever else, might solve their problem if they tackled the
problem 'correctly'.
my 2c
--
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com
Hash: SHA1
On Sun, Aug 2, 2009 at 3:17 AM, Jeff Lindsay wrote:
>
>> While I agree with you that the server/client distinction will start to
>> become meaningless, I think webhooks-to-the-client has more potential than
>> you suggest.
>
I had Tony's same thoughts:
>> I am, of course, biased ;-) , but to me having a single generic protocol for
>> participating bidirectionally in the HTTP ecosystem beats each app developer
>> repetitively building ad-hoc solutions to the "last-mile" problem every time
>> there is one.
tunnel example in mind.
Jeff asks:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.8)
iEYEARECAAYFAkp05IoACgkQL/DTCig+Nhco8ACfRrCdUiz6avgTctqGIIMmWJrF
dgYAn0SIOAslXsE/TTmBjkDJKYGgEK54
=HFt4
-----END PGP SIGNATURE-----
> I would love to be convinced. I guess the primary advantage is having
> direct communication with local apps? What are some great use-cases
> for webhooks-to-the-client?
web hooks in a way Tony suggests.
http://www.fileguru.com/Reverse-HTTP-Starter/info
The purpose of the link is to show that it does seem people use things
in wierd, wonderful and possibly even non-optimal ways.
I'd go further and observe that this is the 'problem' IT gurus have to
live with, the result of allowing people without formal comp.sci.
training to own computers/pdas/phones and have easy network
connectivity... they learn to solve a problem (even ones that don't
exist) overtime, by iteration/tiral-and-error and in a ways that can
resemble a random walk.
The only observation I'd like you to seriously consider is: please
don't /only/ think about webhooks in terms of having a large global
provider (google, etc.), or even in terms of a middle-man/hub
mediating between several providers.
I think there can be legitimate, and to the users, very important,
peer-to-peer use cases.... people know when their computers are on -
they are on when they are using them :)
These are use cases that people might be too shy/embarassed to promote
because they know they are out of their depth (in comp. sci. terms)
and they know they have only manged to cobble something together that
'just' works....
I suppose my point is webhooks offers an interesting way for people to
hook together the work they do on their computers/pdas/phones - all
without a middle man in sight.
In this respect I think Tony's observations are important.
Further more I think ideal-world/technically-correct counter points
don't make people's real-world-needs go away, nor will they stop all
those pesky users employ computers in ways that they weren't supposed
to - I'm not saying you shouldn't feel free to write to your
congressional rep about it ;)
Yes, no doubt some individuals will use a solution not knowning ipv6,
or whatever else, might solve their problem if they tackled the
problem 'correctly'.
my 2c
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com
Jeff Lindsay
Aug 2, 2009, 1:34:52 AM8/2/09
to webh...@googlegroups.com
Reverse HTTP Starter is definitely cool ... and I agree (and
encourage!) that people do weird or unconventional things with
technology (in a way, that's what webhooks are doing)... anyway, I'm
not saying webhooks to the client is a bad idea, just not a
particularly interesting proposition to me. It's a vitamin not a pill.
A nice-to-have, but not a game changer. I suppose I'm trying to say I
don't find it central to the power of webhooks. It's all very cool
stuff nonetheless, so I'm glad you guys are building things with it.
^_^
encourage!) that people do weird or unconventional things with
technology (in a way, that's what webhooks are doing)... anyway, I'm
not saying webhooks to the client is a bad idea, just not a
particularly interesting proposition to me. It's a vitamin not a pill.
A nice-to-have, but not a game changer. I suppose I'm trying to say I
don't find it central to the power of webhooks. It's all very cool
stuff nonetheless, so I'm glad you guys are building things with it.
^_^
Tony Garnock-Jones
Aug 4, 2009, 11:41:11 PM8/4/09
to webh...@googlegroups.com
2009/8/2 Jeff Lindsay <prog...@gmail.com>
I completely agree with this. Webhooks are awesome even when it's difficult to set up HTTP servers :-)
I suppose I'm trying to say I
don't find it central to the power of webhooks.
I completely agree with this. Webhooks are awesome even when it's difficult to set up HTTP servers :-)
robin
Aug 5, 2009, 7:01:19 AM8/5/09
to WebHooks
On Aug 1, 8:07 pm, Jeff Lindsay <progr...@gmail.com> wrote:
> Twitter would benefit by expanding their ecosystem by lowering the
> barrier to entry in making extensions to Twitter.
really a matter of server/client or server/server, though I too don't
really see much point in web hooks to client as this seems to me to
just broadcast results, but actually changing the ecosystem of the
web. Since the early days when Engelbart and Kay were working on the
personal computer, they envisaged a computer world that empowered the
user -- two-way links, programmability, modifiability, etc. Engelbart
has spend much of the last 30 years trying to get back to those ideals
(however going in the wrong direction in my mind). What Jeff is
pointing out here, if I can say so, is a real change to the actual
ecosystem of the web, using the ecosystem of the web. That is why web
hooks are so innovative.
Web hooks are also innovative in that they are simple. Sure they can
be implemented in complex ways, and this can be interesting and
powerful, but they also can be implemented in dead simple ways, by
people who are not programmers or who are just beginning. Twitter
might just be a really good environment for starting to show off the
power of web hooks, mostly because it has a huge diversity of users.
Just one last notice, I think the first research grant that officially
mentions web hooks went in to the NSF last week.
robin
Aug 5, 2009, 7:01:31 AM8/5/09
to WebHooks
> Twitter would benefit by expanding their ecosystem by lowering the
> barrier to entry in making extensions to Twitter.
> barrier to entry in making extensions to Twitter.
Matt B
Aug 7, 2009, 12:45:32 AM8/7/09
to WebHooks
I am interested in a solution for real time to the browser as well.
Events and alerts in near real-time make the web environment more like
a desktop environment regardless of the type of notifications being
sent.
I started reading about webhooks hoping it was an option but so far
have to agree that webhooks aren't meant to solve this problem. But
while webhooks are solving the problem of polling app to server, what
about that problem for the client? Doesn't the client still have to
poll a web service (the one that receives your webhook post) for an
update with AJAX? How do we solve the latency at the client without
polling? You can do this with applets...but then the user has to
install something to make it work. It would be nice to have a
standard that is accepted by all browsers to provide the listener for
the data being posted. Or am I missing something? I guess I don't
see why latency matters from app to server, but client to app can be
ignored.
Events and alerts in near real-time make the web environment more like
a desktop environment regardless of the type of notifications being
sent.
I started reading about webhooks hoping it was an option but so far
have to agree that webhooks aren't meant to solve this problem. But
while webhooks are solving the problem of polling app to server, what
about that problem for the client? Doesn't the client still have to
poll a web service (the one that receives your webhook post) for an
update with AJAX? How do we solve the latency at the client without
polling? You can do this with applets...but then the user has to
install something to make it work. It would be nice to have a
standard that is accepted by all browsers to provide the listener for
the data being posted. Or am I missing something? I guess I don't
see why latency matters from app to server, but client to app can be
ignored.
Jeff Lindsay
Aug 7, 2009, 2:07:43 AM8/7/09
to webh...@googlegroups.com
Webhooks solve part of the problem. But a major part of the problem (producing).
Matt Brown
Aug 7, 2009, 2:45:59 AM8/7/09
to webh...@googlegroups.com
Apparently HTML5 WebSockets could be a solution to the client
http://www.infoq.com/news/2008/12/websockets-vs-comet-ajax
Example using FIrefox
http://www.youtube.com/watch?v=CrV9jJQn_MA
http://www.infoq.com/news/2008/12/websockets-vs-comet-ajax
Example using FIrefox
http://www.youtube.com/watch?v=CrV9jJQn_MA
Jeff Lindsay
Aug 7, 2009, 3:05:28 AM8/7/09
to webh...@googlegroups.com
Yep. Or any of the other dozens of existing solutions.
Matt Brown
Aug 7, 2009, 12:36:08 PM8/7/09
to webh...@googlegroups.com
What other options are there for a thin client?
Jeff Lindsay
Aug 7, 2009, 4:56:21 PM8/7/09
to webh...@googlegroups.com
For a thin client? Well any of the comet-style solutions (which can be done in a lot of ways... some that avoid the pitfalls mentioned in that article). I like Orbited. A project called msgbus has pubsub builtin. Or use a Flash component to open sockets and interface with Javascript. WebSockets will be nice, for sure though. I'm just saying ... you don't have to wait for WebSockets for a solution to the client. People have been doing real-time to the client for 5 years or more.
Ivan Zuzak
Sep 4, 2009, 11:06:24 AM9/4/09
to WebHooks
Just got around to reading this, sorry for reviving a 1-month dead
thread :)
Other than WebSockets, I think Server-sent events (http://www.w3.org/
TR/eventsource/) will be very cool for delivering events to browsers.
It's a lot more focused spec than WebSockets and fits nicely into the
event/notification scenario. From the spec:
"This specification defines an API for opening an HTTP connection for
receiving push notifications from a server in the form of DOM events.
The API is designed such that it can be extended to work with other
push notification schemes such as Push SMS."
Ivan
On Aug 7, 10:56 pm, Jeff Lindsay <progr...@gmail.com> wrote:
> For a thin client? Well any of the comet-style solutions (which can be done
> in a lot of ways... some that avoid the pitfalls mentioned in that article).
> I like Orbited. A project called msgbus has pubsub builtin. Or use a Flash
> component to open sockets and interface with Javascript. WebSockets will be
> nice, for sure though. I'm just saying ... you don't have to wait for
> WebSockets for a solution to the client. People have been doing real-time to
> the client for 5 years or more.
>
>
>
>
>
> On Fri, Aug 7, 2009 at 9:36 AM, Matt Brown <hoopsbw...@gmail.com> wrote:
>
> > What other options are there for a thin client?
>
> > >> >http://shdh.org-- A party for hackers and thinkers
>
> > > --
> > > Jeff Lindsay
> > >http://webhooks.org-- Make the web more programmable
> > >http://shdh.org-- A party for hackers and thinkers
>
> --
> Jeff Lindsayhttp://webhooks.org-- Make the web more programmablehttp://shdh.org-- A party for hackers and thinkershttp://tigdb.com-- Discover indie gameshttp://progrium.com-- More interesting things
thread :)
Other than WebSockets, I think Server-sent events (http://www.w3.org/
TR/eventsource/) will be very cool for delivering events to browsers.
It's a lot more focused spec than WebSockets and fits nicely into the
event/notification scenario. From the spec:
"This specification defines an API for opening an HTTP connection for
receiving push notifications from a server in the form of DOM events.
The API is designed such that it can be extended to work with other
push notification schemes such as Push SMS."
Ivan
On Aug 7, 10:56 pm, Jeff Lindsay <progr...@gmail.com> wrote:
> For a thin client? Well any of the comet-style solutions (which can be done
> in a lot of ways... some that avoid the pitfalls mentioned in that article).
> I like Orbited. A project called msgbus has pubsub builtin. Or use a Flash
> component to open sockets and interface with Javascript. WebSockets will be
> nice, for sure though. I'm just saying ... you don't have to wait for
> WebSockets for a solution to the client. People have been doing real-time to
> the client for 5 years or more.
>
>
>
>
>
> On Fri, Aug 7, 2009 at 9:36 AM, Matt Brown <hoopsbw...@gmail.com> wrote:
>
> > What other options are there for a thin client?
>
> > On Fri, Aug 7, 2009 at 1:05 AM, Jeff Lindsay<progr...@gmail.com> wrote:
> > > Yep. Or any of the other dozens of existing solutions.
>
> > > On Thu, Aug 6, 2009 at 11:45 PM, Matt Brown <hoopsbw...@gmail.com>
> > > Yep. Or any of the other dozens of existing solutions.
>
> > wrote:
>
> > >> Apparently HTML5 WebSockets could be a solution to the client
>
> > >>http://www.infoq.com/news/2008/12/websockets-vs-comet-ajax
>
> > >> Example using FIrefox
>
> > >>http://www.youtube.com/watch?v=CrV9jJQn_MA
>
> > >> On Fri, Aug 7, 2009 at 12:07 AM, Jeff Lindsay<progr...@gmail.com>
>
> > >> Apparently HTML5 WebSockets could be a solution to the client
>
> > >>http://www.infoq.com/news/2008/12/websockets-vs-comet-ajax
>
> > >> Example using FIrefox
>
> > >>http://www.youtube.com/watch?v=CrV9jJQn_MA
>
> > wrote:
> > >> > Webhooks solve part of the problem. But a major part of the problem
> > >> > (producing).
>
> > >> > Webhooks solve part of the problem. But a major part of the problem
> > >> > (producing).
>
> > >> > On Thu, Aug 6, 2009 at 9:45 PM, Matt B <hoopsbw...@gmail.com> wrote:
>
> > >> >> I am interested in a solution for real time to the browser as well.
> > >> >> Events and alerts in near real-time make the web environment more
> > like
> > >> >> a desktop environment regardless of the type of notifications being
> > >> >> sent.
>
> > >> >> I started reading about webhooks hoping it was an option but so far
> > >> >> have to agree that webhooks aren't meant to solve this problem. But
> > >> >> while webhooks are solving the problem of polling app to server, what
> > >> >> about that problem for the client? Doesn't the client still have to
> > >> >> poll a web service (the one that receives your webhook post) for an
> > >> >> update with AJAX? How do we solve the latency at the client without
> > >> >> polling? You can do this with applets...but then the user has to
> > >> >> install something to make it work. It would be nice to have a
> > >> >> standard that is accepted by all browsers to provide the listener for
> > >> >> the data being posted. Or am I missing something? I guess I don't
> > >> >> see why latency matters from app to server, but client to app can be
> > >> >> ignored.
>
> > >> > --
> > >> > Jeff Lindsay
> > >> >http://webhooks.org-- Make the web more programmable
>
> > >> >> I am interested in a solution for real time to the browser as well.
> > >> >> Events and alerts in near real-time make the web environment more
> > like
> > >> >> a desktop environment regardless of the type of notifications being
> > >> >> sent.
>
> > >> >> I started reading about webhooks hoping it was an option but so far
> > >> >> have to agree that webhooks aren't meant to solve this problem. But
> > >> >> while webhooks are solving the problem of polling app to server, what
> > >> >> about that problem for the client? Doesn't the client still have to
> > >> >> poll a web service (the one that receives your webhook post) for an
> > >> >> update with AJAX? How do we solve the latency at the client without
> > >> >> polling? You can do this with applets...but then the user has to
> > >> >> install something to make it work. It would be nice to have a
> > >> >> standard that is accepted by all browsers to provide the listener for
> > >> >> the data being posted. Or am I missing something? I guess I don't
> > >> >> see why latency matters from app to server, but client to app can be
> > >> >> ignored.
>
> > >> > --
> > >> > Jeff Lindsay
> > >> >http://shdh.org-- A party for hackers and thinkers
> > >> >http://tigdb.com-- Discover indie games
> > >> >http://progrium.com-- More interesting things
>
> > > --
> > > Jeff Lindsay
> > >http://webhooks.org-- Make the web more programmable
> > >http://shdh.org-- A party for hackers and thinkers
> > >http://tigdb.com-- Discover indie games
> > >http://progrium.com-- More interesting things
>
> --
> Jeff Lindsayhttp://webhooks.org-- Make the web more programmablehttp://shdh.org-- A party for hackers and thinkershttp://tigdb.com-- Discover indie gameshttp://progrium.com-- More interesting things
Daniel Parker
Sep 4, 2009, 1:27:16 PM9/4/09
to webh...@googlegroups.com
To get this straight: http://www.w3.org/TR/eventsource/ is supposed to be a description of what a browser could/should implement, such as perhaps Firefox's next browser version?
I think this would make sense, that since the DOM is implemented by the browser, the browser would be the one to integrate with this event interface. All the page would have to do is give it a url that is the source for events, and the browser connects to that url and keeps the connection open listening to a stream of DOM events.
This would also call for, in the ruby/rails world, a server plugin, where one process can receive and hold on to all of these browser event-stream requests through the duration of the browser's page session, and allow other processes on the server to send events through it to specific and/or multiple browser sessions.
- daniel parker -
"You have granted me life and steadfast love, and your care has preserved my spirit." Job 10:12
"The LORD is my chosen portion and my cup . . . indeed, I have a beautiful inheritance." Psalm 16:5-6
"Give what you can ... take nothing back!"
- daniel parker -
"You have granted me life and steadfast love, and your care has preserved my spirit." Job 10:12
"The LORD is my chosen portion and my cup . . . indeed, I have a beautiful inheritance." Psalm 16:5-6
"Give what you can ... take nothing back!"
Ivan Zuzak
Sep 4, 2009, 4:08:30 PM9/4/09
to WebHooks
Exactly, Daniel -- this is a spec of a new DOM feature which HTML5
browsers will implement. As a matter of fact, Opera already
implemented it (http://my.opera.com/WebApplications/blog/show.dml/
438711) and webkit-based browsers are also working on it (Chromium -
http://code.google.com/p/chromium/issues/detail?id=19625, WebKit -
http://trac.webkit.org/changeset/47323). Not sure where Firefox is in
this picture.
Anyway, I think you're spot on with the proxy process on the server
which relays events to browsers from other processes. This actually
covers a part of the reversehttp spec and COMET which was poked at
earlier in the thread. We'll probably see even more possibilities/
ideas as the feature gets more publicity. Not sure what this spec does
for the future of webhooks, though.
Ivan
On Sep 4, 7:27 pm, Daniel Parker <dcpar...@gmail.com> wrote:
> To get this straight:http://www.w3.org/TR/eventsource/is supposed to be a
> > > > >> >http://webhooks.org--Make the web more programmable
> > > > >> >http://shdh.org--A party for hackers and thinkers
> > > > >> >http://tigdb.com--Discover indie games
> > > > >> >http://progrium.com--More interesting things
>
> > > > > --
> > > > > Jeff Lindsay
> > > > >http://webhooks.org--Make the web more programmable
> > > > >http://shdh.org--A party for hackers and thinkers
> > > > >http://tigdb.com--Discover indie games
> > > > >http://progrium.com--More interesting things
>
> > > --
> > > Jeff Lindsayhttp://webhooks.org--Make the web more
> > programmablehttp://shdh.org--A party for hackers and
browsers will implement. As a matter of fact, Opera already
implemented it (http://my.opera.com/WebApplications/blog/show.dml/
438711) and webkit-based browsers are also working on it (Chromium -
http://code.google.com/p/chromium/issues/detail?id=19625, WebKit -
http://trac.webkit.org/changeset/47323). Not sure where Firefox is in
this picture.
Anyway, I think you're spot on with the proxy process on the server
which relays events to browsers from other processes. This actually
covers a part of the reversehttp spec and COMET which was poked at
earlier in the thread. We'll probably see even more possibilities/
ideas as the feature gets more publicity. Not sure what this spec does
for the future of webhooks, though.
Ivan
On Sep 4, 7:27 pm, Daniel Parker <dcpar...@gmail.com> wrote:
> To get this straight:http://www.w3.org/TR/eventsource/is supposed to be a
> > > > >> >http://shdh.org--A party for hackers and thinkers
> > > > >> >http://tigdb.com--Discover indie games
> > > > >> >http://progrium.com--More interesting things
>
> > > > > --
> > > > > Jeff Lindsay
> > > > >http://webhooks.org--Make the web more programmable
> > > > >http://shdh.org--A party for hackers and thinkers
> > > > >http://tigdb.com--Discover indie games
> > > > >http://progrium.com--More interesting things
>
> > > --
> > > Jeff Lindsayhttp://webhooks.org--Make the web more
> > programmablehttp://shdh.org--A party for hackers and
Daniel Parker
Sep 5, 2009, 3:50:05 AM9/5/09
to webh...@googlegroups.com
Not sure what this spec does for the future of webhooks, though.
Well, it sorta brings webhooks to the browser. At least, in a small and isolated manner. It'll be a good move.
- daniel parker -
Reply all
Reply to author
Forward
0 new messages