What the HTTP is CouchApp
wiki.couchapp.org
What the HTTP is CouchApp
1–10 of 25 posts
Re: What the HTTP is CouchApp
#2ie, would a user be able to alter the application themselves, and not just their data?
Re: What the HTTP is CouchApp
#3If an app can be replicated to a user's machine, can the user then also manipulate the couchapp's view and design documents using futon or otherwise, even though validation functions are in place? ie, would a user be able to alter the application themselves, and not just their data?
Re: What the HTTP is CouchApp
#4If an app can be replicated to a user's machine, can the user then also manipulate the couchapp's view and design documents using futon or otherwise, even though validation functions are in place? ie, would a user be able to alter the application themselves, and not just their data?
Couch's design documents are protected, even though they are replicated, as you say. Unless I'm misunderstanding your question, your application will be safe from modification, as it will be update-able only by the author.
However, when the user attempts to replicate changes to another server (maybe the original source server, maybe another server not under their control) it is the validation functions on the target server that control which writes are allowed to proceed.
So if my http://jchrisa.net server only allows updates from me (for instance for blog posts), you can still replicate my blog to your machine, and edit posts there, but when you replicate the changes back to my server, they will be rejected by my validation function.
Re: What the HTTP is CouchApp
#5Earlier quoted context omitted.
Couch's design documents are protected, even though they are replicated, as you say. Unless I'm misunderstanding your question, your application will be safe from modification, as it will be update-able only by the author.
Actually, whatever is on the user's machine (or in a Couch in the cloud controlled by the user) is 100% under the control of the user. They are free to alter the application, validations, etc, as they see fit. However, when the user attempts to replicate changes to another server (maybe the original source server, maybe another server not under their control) it is the validation functions on the target server that c…
Re: What the HTTP is CouchApp
#6If an app can be replicated to a user's machine, can the user then also manipulate the couchapp's view and design documents using futon or otherwise, even though validation functions are in place? ie, would a user be able to alter the application themselves, and not just their data?
For those that are still confused a bit, couchapp takes advantage of the fact that couchdb is accessed via a RESTful interface. Documents and databases are identified and accessed with URLs.
Typically your client and couchdb speak JSON to each other. When you GET a resource, you just get back a JSON object.
However:
1. You can change the format of what you get back. You can also return back XML, HTML, XHTML, etc., instead of JSON.
2. You can add attachments to documents. Attachments can be images, html pages, anything. You can specify the content type and couchdb will happily serve those when you click the attachment resource URL.
CouchApp takes advantage of those 2 things. It renders html page templates saved as document attachments, and fills those in with data from some view (read: query), and then returns HTML.
It basically cuts out the traditional middle layer by performing that work inside the database.
Combined with the fact that replication works so well in couchdb, you can just move your web app just by replicating a database: a one-step process.
Re: What the HTTP is CouchApp
#7If an app can be replicated to a user's machine, can the user then also manipulate the couchapp's view and design documents using futon or otherwise, even though validation functions are in place? ie, would a user be able to alter the application themselves, and not just their data?
Couch's design documents are protected, even though they are replicated, as you say. Unless I'm misunderstanding your question, your application will be safe from modification, as it will be update-able only by the author.
Re: What the HTTP is CouchApp
#8Earlier quoted context omitted.
Actually, whatever is on the user's machine (or in a Couch in the cloud controlled by the user) is 100% under the control of the user. They are free to alter the application, validations, etc, as they see fit. However, when the user attempts to replicate changes to another server (maybe the original source server, maybe another server not under their control) it is the validation functions on the target server that c…
Thank you; that is what I meant to explain, but you were much more clear. I guessed that wil was asking about the safety of his own application once replicated by others, because I don't see the concern of having users replicate their own copy, as long as the damage is contained.
So any app written on couchapp can be considered to be modified by the end user if it's replicated to their machine. Then any application where you don't want users fiddling around with your 'source' is out of the question.
That said, there's plenty of applications that you'd want to pass along with the user's own data that you'd want the end users to fiddle with and improve.
With that in mind then, I'm guessing you can have validation functions that allow you to selectively update the design documents that you want from another person's changes, just as I can selectively replicate data from another person's copy of the couchapp.
Re: What the HTTP is CouchApp
#9I'm pretty sure the fragility of the code is as much down to the person writing it as it is to the platform. I don't think it's fair to say that application servers are inherently fragile; run Python or Java apps on App Engine and you're unlikely to ever have a genuine scaling problem...
BTW is that how we quote text here?
Re: What the HTTP is CouchApp
#10In fact, the bad old days are still with us, as most applications still rely on fragile custom code, running in an application server like Ruby on Rails, Python's Django, or some kinda Java thing. I'm pretty sure the fragility of the code is as much down to the person writing it as it is to the platform. I don't think it's fair to say that application servers are inherently fragile; run Python or Java apps on App Eng…
There isn't a strong consensus. I've seen e-mail > quoting (as I used), italics, "quotes", etc. It usually isn't a big deal, unless using several kinds of quoting makes your intent unclear.