On Wed, Oct 1, 2008 at 6:33 PM, Darren New <[EMAIL PROTECTED]> wrote: > Bob La Quey wrote: >> >> A good example of a RESTish approach is NetKernel. See http://1060.org/ > > Just going thru the whitepaper at > http://www.1060research.com/resources/docs/ROCForDevelopers.pdf > by the time they get to page six, they're making incorrect assertions about > how great their stuff is. It's good to know that they, for example, can > aggressively cache the result of an SQL select call, even though the data in > the actual database has changed.
Not all of the data has changed. Selective smart caching is not necessarily that difficult. >It's also good to know that because they're > using XML, they're not "brittle" with respect to the types of data they > return. Let them change <symbol> to a URI and watch stuff break. He, he ... not a bad point. > REST really only works well when you have data that isn't changing, expiring > frequently, and etc. Not really. Caching only works well etc. REST is not just caching. >What's the URI for "IBM's current stock price"? how about http://www.ibm.com/current_stock_price/ There is absolutely no reason why that URI cannot return the current stock price. We do this kind of mapping all the time in Django. I can probably write the code to do that in about 15 minutes. Using any of a number of Python web frameworks it would require little more than mapping that url to a function that looked up the current IBM price and returned ah HTML page with the price embedded in it. I really do not understand your lament. > Stateless service design is a major reason the Web scales to a global > information application. > """ > Nonsense. There are huge numbers of highly stateful web sites like Amazon > that scale just fine. The network with the most state in it is also the > biggest and busiest (the PSTS). What makes the web scale to a global > information application is the huge piles of money that's thrown at it. > There are much better ways of getting scaling, like the store-and-forward > semantics of email. If you discount all the sites that actually, you know, > have state, like Amazon, Facebook, GMail, etc, then sure, you can dispatch > any request to any server. Session is state. I will grant you that. But it is one state per session. Roughly equivalent to spawning one server per session. Not that big a problem. > "active:generateConfig" > Very RESTful, that. NOT! Especially when the micro-kernel starts caching > the results, eliminating the value of having the configuration actively > generated. Same inputs = same outputs so the second time through you cache. This really not that hard to understand. for instance suppose I need to calculate y = sin(x). Now two ways at the extremes of spece, time trade off are: 1) solve the diffeerntial equation for sin(x). This will take some time but not much space for the data. 2) Use a table, look up the value. Takes space but not much time. then there is always 3) Mix the two and use interpolation. Now 1) can be thought of as active, 2) as a cache. Start with 1) and fill in the table for 2). One never needs to use 1) except the first time an argument is encountered. A hash of the arguments points to the output. If null then calculate. This is not difficult. It simply falls out as a natural consequence functional programing of which REST is an example. > "active:[EMAIL PROTECTED]@ffcpl:/pictures/boxes.png" > I'm not sure that's even a valid URL, or that if it is the scheme is going > to be "active". > > """ > The gate keeper can then examine the request and its context for security > credentials ... > """ > Would be nice if they talked about what kind of security credentials you > have, given that everything's identified by a URI. The request carries such stuff ... you tell me though. What is needed? I am confidant that you know far more about security than I ever will. I am also thankful for that fact :) > I actually think that while not RESTful, the Singularity work does a much > better job of decoupling than this stuff does. I do know nothing of Singularity. I will have to explore it. >I would think any big program > where all the layers are linked by untyped strings is going to be awful to > maintain. That's just a guess, tho. I mean, how would you even look at a > program and figure out what URIs it might ask for? How do you manage all > these baroque rewrite rules, just to talk to the database full of state? You are seeing problems I do not. I am using this type of thing with a simple urls.py file to map urls to python functions in complex websites (See Django.) I find the approach works well and is quite simple both to implement and to understand. Clearly, YMMV. >>> There are a number of ways to make things loosely coupled. REST is one, >>> that >>> only works well if your problem fits into that sort of domain. Almost >>> none >>> of the systems I've seen actually implement REST properly. >> >> I would like to see some other good examples. > > Good examples of what, specifically? Of "a number of ways to make things loosely coupled." which is a direct quote from your statement, eh? >>> For example, any web site with a custom login page isn't REST. Amazon's >>> cloud stuff isn't REST. They're all RESTish, but fail in the details >>> that >>> give you the benefits of REST. >> >> I understand the login point as follows: sessions break REST. > > Yes. The same request can't go to a different server with the same data and > work. > > The Amazon stuff fails because altho there aren't sessions, it encodes the > user identification in the data (the login problem) and doesn't actually > give you URLs inside the results. If you don't know what parts of the XML > actually describe URLs and which don't, you can't parse the result. > > CouchDB is about as close to an actual REST service I've seen. > >> Is that your point? > > One point of REST is to allow caching in the network and such. If you have a > login page, you aren't caching stuff. SSL breaks REST. Cookies break REST. > Most everything people use to do actual applications breaks REST. SSL I will grant you. You are not going to cache SSL. A session cookie effectively creates a personal server after which REST works just fine. I am not a REST fundamentalist, "There is no God but REST," but you are not making much of a case against RESTful styles. You seem to be confusing REST with caching among other things. Caching != REST though REST often enhances caching. BobLQ -- KPLUG-LPSG@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
