3 ms·

One thing I haven't seen anyone mention: How this affects one's ability to be acquired by anyone other than Google in the future! I think it safely rules out be

by smoody 19y ago

One thing I haven't seen anyone mention: How this affects one's ability to be acquired by anyone other than Google in the future! I think it safely rules out being acquired by Microsoft, Yahoo, and the like. But what about other customers who want to integrate your apps with theirs? I think that then rules out MySpace, Facebook, and plenty of others. That brings us to companies that don't really care about stuff like that. The list gets small pretty quickly. With the exception of Google -- and they don't have to acquire you because they already have you locked-in! :-) This isn't an issue with EC2 because EC2 apps can run anywhere the proper distro is located (assuming you don't rely too much on other AWS services).

tonystubblebine 19y ago
How do you figure? What web app isn't required to port to new infrastructure when they're acquired. Sure MSFT is at odds with Google, but they were at odds with Unix when they purchased Hotmail (ran on Unix infrastructure for awhile after acquisition even). Then they ported. Assuming the port goes well, it probably makes a nice press release also.
subwindow 19y ago
The code and user base (the two most valuable parts of a startup) will still exist and could still be ported to another hardware architecture.
- daleharvey 19y ago
  with the users api your users cannot be transferred, they are google users who can use your application, it isnt openid, you cant chuck this on another computer and have remote authentication. anything to do with your code that stores data, interfaces with external data / services, runs new threads etc pretty much everything that makes it useful, cannot be ported, by 'hardening' the language sandbox, they tie you into their api. their query language is even google specific. any application written on this platform looks to need to be entirely rewritten from scratch to port to another architecture
  - apathy 19y ago
    with the users api your users cannot be transferred, they are google users who can use your application, it isnt openid, you cant chuck this on another computer and have remote authentication. I wonder, though -- what if you used something like a remote REST interface to do authentication, passing MD5'ed or SHA'ed passwords as one of the arguments, and then based auth on that? Google wouldn't like it, but technically it appears to be within the scope of the TOS. Very, very good point, though... users and data are basically the only things that matter for this type of application. I did find one of your other points spurious, though: their query language is even google specific. Oh for crying out loud -- if you can't write a Perl one-liner to convert every instance of GQL to SQL with bind variables, or if you don't already use placeholders in any instance of raw SQL in your own code, you've got worse problems than that. This is the least of the problems IMHO. Something has occurred to me regarding NumPy, SciPy, R, etc. Since it's Google's CPU time, it's not my problem if a loop or matrix calculation is inefficient. I'm going to deploy some grad students to stress test their TOS... :-)
    - daleharvey 19y ago
      I havent looked deep into it, buts the docs mentioning that it was a crud datastore engine, which means there is no 1-1 relationship with sql, by the positioning of the rest of the api, I dont imagine the more complex functionality google will introduce will align with the current standards either
      - apathy 19y ago
        * I dont imagine the more complex functionality google will introduce will align with the current standards either* Probably not, but again, you don't necessarily have to use the bits that lock you in :-) Nothing new under the sun here...

by smoody 19y ago

tonystubblebine 19y ago

How do you figure? What web app isn't required to port to new infrastructure when they're acquired. Sure MSFT is at odds with Google, but they were at odds with Unix when they purchased Hotmail (ran on Unix infrastructure for awhile after acquisition even). Then they ported. Assuming the port goes well, it probably makes a nice press release also.

subwindow 19y ago

The code and user base (the two most valuable parts of a startup) will still exist and could still be ported to another hardware architecture.

daleharvey 19y ago
with the users api your users cannot be transferred, they are google users who can use your application, it isnt openid, you cant chuck this on another computer and have remote authentication. anything to do with your code that stores data, interfaces with external data / services, runs new threads etc pretty much everything that makes it useful, cannot be ported, by 'hardening' the language sandbox, they tie you into their api. their query language is even google specific. any application written on this platform looks to need to be entirely rewritten from scratch to port to another architecture
- apathy 19y ago
  with the users api your users cannot be transferred, they are google users who can use your application, it isnt openid, you cant chuck this on another computer and have remote authentication. I wonder, though -- what if you used something like a remote REST interface to do authentication, passing MD5'ed or SHA'ed passwords as one of the arguments, and then based auth on that? Google wouldn't like it, but technically it appears to be within the scope of the TOS. Very, very good point, though... users and data are basically the only things that matter for this type of application. I did find one of your other points spurious, though: their query language is even google specific. Oh for crying out loud -- if you can't write a Perl one-liner to convert every instance of GQL to SQL with bind variables, or if you don't already use placeholders in any instance of raw SQL in your own code, you've got worse problems than that. This is the least of the problems IMHO. Something has occurred to me regarding NumPy, SciPy, R, etc. Since it's Google's CPU time, it's not my problem if a loop or matrix calculation is inefficient. I'm going to deploy some grad students to stress test their TOS... :-)
  - daleharvey 19y ago
    I havent looked deep into it, buts the docs mentioning that it was a crud datastore engine, which means there is no 1-1 relationship with sql, by the positioning of the rest of the api, I dont imagine the more complex functionality google will introduce will align with the current standards either
    - apathy 19y ago
      * I dont imagine the more complex functionality google will introduce will align with the current standards either* Probably not, but again, you don't necessarily have to use the bits that lock you in :-) Nothing new under the sun here...