Also, don't underestimate the native power of JavaScript. http://code.google.com/p/jspdf/
Hehe. On 12 Aug 2010, at 15:11, Nitin Borwankar wrote: > Could not the same "criticism" be leveled at any database - that it cannot do > computationally complex tasks? > > Almost by definition a database is not expected to do those things, but > rather to make data storage, indexing and access fast and easy. > > So I am not sure CouchDB has any unique deficiencies in that regard. > > Cheers, > > Nitin > > Sent from my mobile Internet device > > > On Aug 11, 2010, at 10:43 AM, Victor Stan <[email protected]> wrote: > >> So in going through the CouchDB book, and playing a bit more with it, >> as well as thinking about the needs of my own projects I came to >> realize that perhaps there are some things that I need to better >> understand or that couch db may not be able to handle because of it's >> inherent nature. I will like it of you folks helped me shed some light >> on these discoveries/opinions... >> >> The way I see it now, Couch DB is a really good platform for creating >> highly scalable apps that are restricted to the data in the database, >> and whatever JavaScript can do in a web browser. This means that Couch >> DB can do anything that is implemented in a web browser like HTML, >> CSS, SVG, Web3D/webGL(in the future/nightly builds) and whatever >> documents exist in the database. >> >> However, what CouchDB can't handle is anything that needs to be >> computed, which relies on specific libraries, outside the scope of >> CouchDB itself, such as for example, image processing, video/audio >> processing/encoding, cryptography(although maybe some js options >> exist) >> >> This means that CouchDB can excell at information and data that is >> stored exactly in the way that it is meant to be displayed (if it is >> not computed on the fly, or text) but can't handle any 'heavy' >> computation on binary data. This would limit the extend that CouchApp >> can be seen as a true 'application' development platform, to the >> extent that it is pretty much limited to dealing with database >> introspection, input/output, but no complex computation (that is >> beyond map/reduce)... >> >> How much of that is right/wrong? >> >> >> I appreciate all enlightening information from you! >> >> Victor Stan
