Loading ...
Sorry, an error occurred while loading the content.

google gears in Myspace

Expand Messages
  • Lucas Gonze
    This use of Google Gears to move processing from the server to the client is basically a p2p algorithm to enable scaling:
    Message 1 of 8 , May 28, 2008
    • 0 Attachment
      This use of Google Gears to move processing from the server to the client
      is basically a p2p algorithm to enable scaling:

      http://www.techcrunch.com/2008/05/28/myspace-shows-facebook-how-its-done-google-gears-to-power-messaging/
    • Lucas Gonze
      Yahoo s BrowserPlus is in a similar space as Google Gears: http://browserplus.yahoo.com
      Message 2 of 8 , May 28, 2008
      • 0 Attachment
        Yahoo's BrowserPlus is in a similar space as Google Gears:
        http://browserplus.yahoo.com



        On Wed, 28 May 2008, Lucas Gonze wrote:

        >
        > This use of Google Gears to move processing from the server to the client
        > is basically a p2p algorithm to enable scaling:
        >
        > http://www.techcrunch.com/2008/05/28/myspace-shows-facebook-how-its-done-google-gears-to-power-messaging/
        >
        >
        >
        > ------------------------------------
        >
        > Announce or discover P2P conferences on the P2P Conference Wiki at
        > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferencesYahoo! Groups Links
        >
        >
        >
        >
      • Jim McCoy
        It s still simple client-server. I am not processing your message history, nor providing a remote cache for data that is not specific to my interaction with
        Message 3 of 8 , May 29, 2008
        • 0 Attachment
          It's still simple client-server. I am not processing your message
          history, nor providing a remote cache for data that is not specific to
          my interaction with the service. It is a scaling aide, but I can't
          see how this is in any way p2p.

          On May 28, 2008, at 12:45 PM, Lucas Gonze wrote:

          >
          > This use of Google Gears to move processing from the server to the
          > client
          > is basically a p2p algorithm to enable scaling:
          >
          > http://www.techcrunch.com/2008/05/28/myspace-shows-facebook-how-its-done-google-gears-to-power-messaging/
          >
          >
        • Lucas Gonze
          You re right that it s not a peer to peer interaction. But then again, seti@home wasn t either. What s interesting about this from the perspective of
          Message 4 of 8 , May 30, 2008
          • 0 Attachment
            You're right that it's not a peer to peer interaction. But then again,
            seti@home wasn't either.

            What's interesting about this from the perspective of distributed
            computing is the rebalancing of the traditional relationship between
            authoritative nodes and the client. I'm especially inspired by the subtle
            changes in how we think of a browser's proper role.

            I think that a lot of people are going to invade Flash's traditional turf,
            even though it's a suicide mission when installed base is key. The reason
            they'll do it anyway is because there are web apps that can't be built
            without a new client-side component, and Adobe alone can't provide for all
            of them.

            On Thu, 29 May 2008, Jim McCoy wrote:

            > It's still simple client-server. I am not processing your message
            > history, nor providing a remote cache for data that is not specific to
            > my interaction with the service. It is a scaling aide, but I can't
            > see how this is in any way p2p.
            >
            > On May 28, 2008, at 12:45 PM, Lucas Gonze wrote:
            >
            >>
            >> This use of Google Gears to move processing from the server to the
            >> client
            >> is basically a p2p algorithm to enable scaling:
            >>
            >> http://www.techcrunch.com/2008/05/28/myspace-shows-facebook-how-its-done-google-gears-to-power-messaging/
            >>
            >>
            >
            >
            > ------------------------------------
            >
            > Announce or discover P2P conferences on the P2P Conference Wiki at
            > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferencesYahoo! Groups Links
            >
            >
            >
            >
          • Clay Shirky
            ... Right, but this is b/c peer-to-peer was always a misnomer, when the important pattern was decentralization. ... What are the things Adobe can t provide?
            Message 5 of 8 , May 30, 2008
            • 0 Attachment
              > You're right that it's not a peer to peer interaction. But then again,
              > seti@home wasn't either.

              Right, but this is b/c peer-to-peer was always a misnomer, when the
              important pattern was decentralization.

              > I think that a lot of people are going to invade Flash's traditional turf,
              > even though it's a suicide mission when installed base is key. The reason
              > they'll do it anyway is because there are web apps that can't be built
              > without a new client-side component, and Adobe alone can't provide for all
              > of them.

              What are the things Adobe can't provide? (Genuinely asking -- I don't
              know well enough what is and isn't possible.)

              -c
            • Lucas Gonze
              ... And on that level, moving processing from the server to the client (even within the browser) does fit the pattern. ... I can guess at specifics, but
              Message 6 of 8 , May 30, 2008
              • 0 Attachment
                On Fri, 30 May 2008, Clay Shirky wrote:

                >> You're right that it's not a peer to peer interaction. But then again,
                >> seti@home wasn't either.
                >
                > Right, but this is b/c peer-to-peer was always a misnomer, when the
                > important pattern was decentralization.

                And on that level, moving processing from the server to the client (even
                within the browser) does fit the pattern.


                >
                >> I think that a lot of people are going to invade Flash's traditional turf,
                >> even though it's a suicide mission when installed base is key. The reason
                >> they'll do it anyway is because there are web apps that can't be built
                >> without a new client-side component, and Adobe alone can't provide for all
                >> of them.
                >
                > What are the things Adobe can't provide? (Genuinely asking -- I don't
                > know well enough what is and isn't possible.)

                I can guess at specifics, but they'll have to be be extrapolated from
                evidence of demand for non-Adobe browser plugins. Google Gears and Yahoo
                BrowerPlus are both evidence that Adobe is leaving some developer needs
                unmet.

                What are those needs? My first guess is that Adobe can't do client-side
                inovation on behalf of the whole web, and when an innovator has an idea
                they can't just wait for Adobe to support the client-side parts.

                If that's too clever an answer, I'd say that the volume of worthy
                client-side features is what Adobe can't handle. It's not that they can't
                do any one feature, it's that they can't do them all. Otherwise Gears and
                BrowsePlus wouldn't have come into existence (Speaking from the Yahoo
                perspective, albeit ex-Y, I can tell you that B+ met a need compelling
                enough to get funding and make it through the product pipeline. Yahoo
                rarely does gee-whiz products).

                For example, the Foxytunes client is a generic interface between the
                browser and a zillion desktop music players. There was clear economic
                value to it, but not of the kind that would enable Adobe to build it.
                This is a job for a specialist.

                -Lucas
              • Lucas Gonze
                Another data point for interesting work in this space. http://kaboomerang.com/blog/ For the curious, CloudKit is coming together as an SDK delivered by way
                Message 7 of 8 , May 30, 2008
                • 0 Attachment
                  Another data point for interesting work in this space.

                  http://kaboomerang.com/blog/
                  "
                  For the curious, CloudKit is coming together as an SDK delivered by way of
                  a ruby gem. The installed gem will allow anyone to generate a small, fast
                  web app that supports OpenID logins and OAuth API authorization right out
                  of the box. Stealing liberally from my GWT on Rails plugin, CloudKit will
                  keep data models in your web app in sync with the models in your
                  distributed, online/offline desktop apps (built with the same HTML, CSS,
                  and JavaScript UI on both sides). The center of it all is a tightly
                  optimized bit of JavaScript known as the Application Context.

                  This Application Context is kind of like the MCP in Tron, minus the evil
                  part. It knows when it is running in a browser or on the desktop and makes
                  decisions about what to do when the network connection is unavailable.
                  Local SQLite storage is used for both speed and network fault tolerance.
                  Based on launch times, network state, and web service information, the
                  wannabe MCP updates client apps to the latest version, migrates their data
                  models to match the server versions, and synchronizes data that is stale
                  on either side.
                  "

                  On Fri, 30 May 2008, Lucas Gonze wrote:

                  >
                  >
                  > On Fri, 30 May 2008, Clay Shirky wrote:
                  >
                  >>> You're right that it's not a peer to peer interaction. But then again,
                  >>> seti@home wasn't either.
                  >>
                  >> Right, but this is b/c peer-to-peer was always a misnomer, when the
                  >> important pattern was decentralization.
                  >
                  > And on that level, moving processing from the server to the client (even
                  > within the browser) does fit the pattern.
                  >
                  >
                  >>
                  >>> I think that a lot of people are going to invade Flash's traditional turf,
                  >>> even though it's a suicide mission when installed base is key. The reason
                  >>> they'll do it anyway is because there are web apps that can't be built
                  >>> without a new client-side component, and Adobe alone can't provide for all
                  >>> of them.
                  >>
                  >> What are the things Adobe can't provide? (Genuinely asking -- I don't
                  >> know well enough what is and isn't possible.)
                  >
                  > I can guess at specifics, but they'll have to be be extrapolated from
                  > evidence of demand for non-Adobe browser plugins. Google Gears and Yahoo
                  > BrowerPlus are both evidence that Adobe is leaving some developer needs
                  > unmet.
                  >
                  > What are those needs? My first guess is that Adobe can't do client-side
                  > inovation on behalf of the whole web, and when an innovator has an idea
                  > they can't just wait for Adobe to support the client-side parts.
                  >
                  > If that's too clever an answer, I'd say that the volume of worthy
                  > client-side features is what Adobe can't handle. It's not that they can't
                  > do any one feature, it's that they can't do them all. Otherwise Gears and
                  > BrowsePlus wouldn't have come into existence (Speaking from the Yahoo
                  > perspective, albeit ex-Y, I can tell you that B+ met a need compelling
                  > enough to get funding and make it through the product pipeline. Yahoo
                  > rarely does gee-whiz products).
                  >
                  > For example, the Foxytunes client is a generic interface between the
                  > browser and a zillion desktop music players. There was clear economic
                  > value to it, but not of the kind that would enable Adobe to build it.
                  > This is a job for a specialist.
                  >
                  > -Lucas
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > Announce or discover P2P conferences on the P2P Conference Wiki at
                  > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferencesYahoo! Groups Links
                  >
                  >
                  >
                  >
                • Adam Fisk
                  ... Another obvious one is heavier-lifting decentralized services like distributing large files and VoIP, although Flash 10 will at the very least change that
                  Message 8 of 8 , Jun 12, 2008
                  • 0 Attachment
                    >
                    > What are the things Adobe can't provide? (Genuinely asking -- I don't
                    > know well enough what is and isn't possible.)
                    >

                    Another obvious one is heavier-lifting decentralized services like distributing large files and
                    VoIP, although Flash 10 will at the very least change that for VoIP. Webapps that want to
                    seamlessly take advantage of decentralized file distribution and VoIP have to look elsewhere
                    as of now.

                    -Adam
                  Your message has been successfully submitted and would be delivered to recipients shortly.