GAE is certainly a refreshing development. most of the code we write are redundant, in the sense, some place its already written, but we still keep writing it because we need to use it in *our* own context. though we do resue code by using packaged libraries, there is significant code for plumbing, etc. The other side is ofcourse deployment. Huge costs go into running a data center. though the hosted farms solve this to an extent, GAE's level of abstraction is fascinating. I mean why bother about that particular RDBMS, or this particular hard disk size, or this specific processor running that particular OS version? and which patch, and which release. I mean think about this wehere you have more than a handful of servers. you will be spending time and money on something unrelated to business. GAE is welcome change in the IT/development world. wishing it all success.
--GS http://code-almighty.blogspot.com On Dec 6, 3:44 pm, kang <areyouloo...@gmail.com> wrote: > a very good post > > > > > > On Sat, Dec 6, 2008 at 2:42 AM, rvjcallanan <vinc...@callanan.ie> wrote: > > > I am about to take the GAE plunge (at least in the experimentation > > sense). > > I understand the current irritations and I am hopeful that these will > > be overcome in due course > > > But I am very curious how far Google can take this thing... > > > A key question on everyone's mind: > > > Can we assume that GAE developers will eventually be able to produce > > GAE apps with similar complexity, reliability, scalability and > > performance ballparks as Gmail, subject of course to hosting fees? > > > If the answer to that question is "YES", then I am am convinced that > > GAE will eventually be able to host sophisticated financial > > applications that are not currently in the GAE sweetspot, e.g. > > accounts, payroll, etc > > > Or would it be more realistic to assume that GAE developers will never > > really be able to leverage what Gmail's developers can leverage? > > > Looking beyond the Gmail comparison, I see lots of problems with the > > GAE datastore for financial applications e.g. the absence of joins, > > aggregation, etc. I understand that these limitations are inherent to > > the BigTable paradigm, yet I already see posts by developers showing > > how these limitations can be overcome. Solutions tend to revolve > > around de-normalisation and other forms of data redundancy together > > with a sizable smattering of code trickery. All very, very botchy and > > alien to the GAE philosophy of removing much of the the tedium of web > > development. > > > I am wondering if it will ever be possible to write an abstraction > > layer that will present the underlying GAE datastore as an SQL > > database albeit at a cost in terms of data efficiency, CPU cycles and > > bandwidth...or is this completely missing the point? > > > Bear in mind that I am thinking a few years down the road. > > -- > Stay hungry,Stay foolish.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
