User:Zero Linden/Office Hours/2007 Nov 27
< User:Zero Linden/Office Hours
Jump to navigation
Jump to search
Revision as of 13:55, 9 December 2007 by Tao Takashi (talk | contribs) (added chatlog about AWG login process)
| Zero Linden: | As I always am, VL! | |
| Vicero Lambert: | lol | |
| Malburns Writer: | Hi Tao | |
| Kooky Jetaime: | hmm 830.. I might actually start comming then hehehe..thats... 11:30 for me | |
| Zero Linden: | So - back to log in | |
| Burhop Piccard: | (my productivity went up 10% when they put a starbucks by my office) | |
| Zero Linden: | This is phase 1 here | |
| Vicero Lambert: | lol @ burhop | |
| Zero Linden: | My idea is that this runs as follows | |
| Zero Linden: | 1: viewer contacts service (well known DNS name based on domain of your avatar identity) with { first-name, last-name, | |
| Zero Linden: | credential (like password), and some indicator of level of service desired) | |
| Zero Linden: | } | |
| Jarod Godel: | like jarod-godel.org? | |
| Zero Linden: | steps 2 and 3 here are internal and we won't be specing | |
| Morgaine Dinova: | Or any name ... that's subgrid dependent, some grids may have different av name policies. | |
| Vicero Lambert: | vicerolambert.hellokitty.secondlife.com | |
| Tao Takashi: | this is all encoded in LLSD? | |
| Jarod Godel: | ok. so it's a "grid" identity. thanks. | |
| Tao Takashi needs to check out the recently released libraries | ||
| Zero Linden: | nono, like services.agent.agni.lindenlab.com | |
| Vicero Lambert: | ahh | |
| Zero Linden: | or even login.agni,lindenlab.com | |
| Jarod Godel: | ok | |
| Zero Linden: | We need to agree on how a viewer knows where to go - right now, it is baked into the viewer, though specifiable on the command line | |
| Zero Linden: | which is how you use the viewer with an OpenSim grid | |
| Zero Linden: | But user's won't know how to spec those things | |
| Zha Ewry: | Most users. will get one with a baked starting point, and never care | |
| Zero Linden: | Even us dev's don't and development versions of the viewer have the magic DNs names baked into the code | |
| Zero Linden: | for each of the development grids | |
| Zero Linden: | I don't know, Zha | |
| Morgaine Dinova: | Clients will provide ways of hiding the details from users, it's not an issue. The key point is that on each subgrid, you have a login URL and one or more login data. | |
| Zero Linden: | I think that most people will be using generic viewers, or one from LL | |
| Jarod Godel: | Zero, treat like like a cookie | |
| Zero Linden: | Do we need to standardize on that mapping - I think we might or we | |
| Tao Takashi: | viewer authors will come up with something I guess ;-) | |
| Ahzzmandius Werribee: | LL could provide a root level "agent domain" dns service. similar to root servers in DNS. | |
| Zero Linden: | are leaving a crucial, first piece of the user expereince out | |
| Jarod Godel: | maybe you start with the baked-in login, but the client should be able to cache others' | |
| Tao Takashi: | and somebody might do some web2.0 like directory service | |
| Jarod Godel: | and, no to mapping | |
| Ahzzmandius Werribee: | part of getting officially into the grid would be to get registered in that root server. | |
| Zha Ewry: | YOu want to make the default behave as easily as possible for 90% of the users.. and.. | |
| Zero Linden: | I'm thinking like this: If I enter my user name as zero.linden.secondlife.com | |
| Zero Linden: | that might map to using services from services.agent.secondlife.com | |
| Zha Ewry: | Note that it's not clear that it's anything but a how to build a client discussion | |
| Tao Takashi: | but is this login service not just the main entry point for one grid? | |
| Jarod Godel: | people/clients need to be able to transact over the web, with random scripts, not just with virtual worlds | |
| Ahzzmandius Werribee: | zero, that looks like a good plan at first blush. | |
| Squirrel Wood: | What about querying a server for a list of known services and let the user pick one instead of having to use the command line switches? | |
| Jarod Godel: | Wait...why are you re-inventing OpenID? | |
| Morgaine Dinova: | Zero: no, that sets a VERY bad precedent to use DNS domain name constraints for av naming. | |
| Zero Linden: | Tao - well, it is the first stage of login, and it is for establishing the connection to the agent domain that controls your agent | |
| Rex Cronon: | no zero. why not just add another textfield where the used can enter the url of the grid that it wants to connect to? | |
| Zero Linden: | Jarod - perhaps we arent' | |
| Jarod Godel: | It sounds like you are | |
| Zero Linden: | what if zero.linden.secondlife.com IS an OpenID | |
| Jarod Godel: | then DNS mapping doesn't matter | |
| Zha Ewry: | Do distinguish, tho.. between client design and protocol | |
| Zha Ewry: | So far.. this.. is client design | |
| Zero Linden: | and the document at that URL (or rather at the implied URL of http://zero.lidnen.secondlife.com/ ) | |
| Zero Linden: | contains a meta tag pointer to the agent domain server name | |
| Zero Linden: | But Zha - | |
| Zero Linden: | it isn't, i think | |
| Zha Ewry: | The first place where it becomes protocl design.. is where I interpret what's at that point | |
| Tao Takashi: | so for each grid I might need a different login server | |
| Zero Linden: | because if we don't spec how you go from a name to that initial DNS name | |
| Tao Takashi: | not sure where the problem here is ;-) just look at the grid's homepage | |
| Zero Linden: | then users, who deal with names, will have a non-standard way of getting in | |
| Zha Ewry: | Ah.. the mapping, maybe | |
| Tao Takashi: | it might even be a link which autostarts the client with the right one.. of course phishing might be a problem them | |
| Zero Linden: | But, let's not get bogged down, | |
| Zha Ewry: | How the client manages it.. not so much | |
| Morgaine Dinova: | To use domain names like this is extremely bad, because it ties logins to domain name delegation. | |
| Zero Linden: | we can just not we may want to spec. or at least reccomend a common approach | |
| Zero Linden: | SO | |
| Squirrel Wood: | initial dns name... client could query server for known services, then let the user choose one? | |
| Rex Cronon: | why would u need a link to restart the client? | |
| Zero Linden: | Well, I'm not tremendously fond of mapping things into DNS - DNS has certain tuned properties | |
| Zero Linden: | and it doesn't work for general things like this | |
| Zero Linden: | BUT most OpenID setups do | |
| Tao Takashi: | maybe we can also postpone this discussion for now ;-) I'd think that first we should have a working login and then we can still finetune these details | |
| Zero Linden: | ANYWAY | |
| Jarod Godel: | I don't mind mapping to dns, but I don't think this needs to be mapped past "login.secondlife.com | |
| Zero Linden: | so - the response to 1 | |
| Zero Linden: | which, if you notice, is MUCH simpler than current login | |
| Zero Linden: | is a single capability (or perhaps a set of capabilites, only one of which is required) | |
| Zero Linden: | the required cap is the "seed-cap" for the agent domain | |
| Morgaine Dinova: | Tao: the trouble is if login is tied to the structure of domain names now, you can't "fine tune" that out later. | |
| Zero Linden: | It is the way the client initiaites #4 | |
| Tao Takashi: | Morgaine: I didn't mean to wait after the first release | |
| Tao Takashi: | but after some prototype | |
| Tao Takashi: | or at least after this meeting ;-) | |
| Ahzzmandius Werribee: | morgaine, that's why I think a dns-like lookup system would be good to provide pointers tot he apropriate servers for each type of task in each user's domain. | |
| Tao Takashi: | it might also depend on how this protocol is used | |
| Morgaine Dinova: | Ahzz: I agree there ... just not that the account names should appear in DNS. | |
| Zero Linden: | In number 4, you invoked the seed-cap with a list of other caps you want: { caps-wanted: [ 'inventory', 'region-tp', 'im', ...] } | |
| Zero Linden: | and the response to that is the list of granted (or denied) capabilities | |
| Ahzzmandius Werribee: | Morgaine, that's decideable later in data specific choices. :-) | |
| Zero Linden: | Morgain - let's put that part of the protocol in a discussion page for now | |
| Jarod Godel: | That I think should be DNS mapped | |
| Morgaine Dinova: | kk | |
| Ahzzmandius Werribee shuts up. :-) | ||
| Tao Takashi: | so how is the call for getting the other caps? | |
| Zero Linden: | So - is this section clear? | |
| Burhop Piccard: | This is good, Zero. | |
| Zero Linden: | In style, at least | |
| Zero Linden: | I think one note | |
| Ahzzmandius Werribee nods. | ||
| Rex Cronon: | which section | |
| Tao Takashi: | could you simply do a GET http://host/<seedcap>/capabilities/inventory ? | |
| Rex Cronon: | ? | |
| Tao Takashi: | I guess you want to group that into one request | |
| Zero Linden: | for now we could / should have a cap called 'legacy-login' - which would return a URL to something that would mostly be the old log-in service (minus the authentication section) | |
| Morgaine Dinova: | Tao: no, just the opposite: some LCC clients don't want all that overhead. | |
| Zero Linden: | this would be the fastest way to get this coded and running | |
| Tao Takashi: | well, I agree for that overhead part | |
| Zero Linden: | Tao | |
| Tao Takashi: | just wanted to know a little how these URLs might look like :) | |
| Jarod Godel: | Tao, I assume "host" there is the sim, not the asset server | |
| Zero Linden: | Ah, well, at present | |
| Zero Linden: | no | |
| Ahzzmandius Werribee: | tao, technical details TBD later. | |
| Tao Takashi: | it's not the sim | |
| Tao Takashi: | we are not yet at the sim level | |
| Zero Linden: | becuase we've found in practice that it is far better to IGNORE everything after the cap in the URL of a request | |
| Zero Linden: | in otherwords, ifyou want a cap | |
| Zero Linden: | to support multiple functions | |
| Tao Takashi: | ah, interesting | |
| Zero Linden: | then you encode what function you want in the body of the request | |
| Tao Takashi: | so why is this better? | |
| Zero Linden: | The reason is this: | |
| Jarod Godel: | (Oh, I thought I saw Zero say "object" somewhere. Sorry.) | |
| Zero Linden: | The way a cap gets granted is that something decides that the viewer should access to some function | |
| Tao Takashi: | host is something in the agent domain, probably your agent host | |
| Gigs Taggart: | is that really restful? | |
| Gigs Taggart: | you no longer identify the asset by the url then | |
| Zero Linden: | it represents that function as an internally accessible URL | |
| Morgaine Dinova: | In general, coupling things together is bad, as it hardwires policy. However, if the "legacy-login" is just an optimization (equiv to asking for lots of caps separately), then fine. | |
| Zero Linden: | like: http://asset.agni.lindenlab.com/123346 | |
| Tao Takashi: | so you then call another URL internally? | |
| Zero Linden: | or http://localhost:12036/map/layer-data | |
| Zero Linden: | Then it asks the capability system to grant a cap to this | |
| Zha Ewry: | Ahm Zero.. as soon as you start posting function into the body.. aren't you gettign away from the big 4 rest verbs and drifting towards SOAPy things? | |
| Zero Linden: | the cap systems generates a random cap to itself, like http://localhost:12040/cap/abcde09876 | |
| Tao Takashi: | ok, so it's basically tinyurl with longer URLs ;-) | |
| Zero Linden: | and internally associates it with the internall | |
| Zero Linden: | YES - exactly | |
| Tao Takashi: | so how would this work for inventory then later on? | |
| Tao Takashi: | say I want to access object with ID 443 | |
| Zero Linden: | Zha - somethings, like granting a cap, are pretty functiony, or POST like | |
| Tao Takashi: | I guess I don't need a cap for every object? | |
| Zero Linden: | just to close the loop here | |
| Zha Ewry: | God, I hope we need a cap per asset server, at best | |
| Zero Linden: | so when the viewer invokes http://localhost:12040/cap/abcde09876 | |
| Neas Bade: | perhaps an example of what the function in the body would be would help | |
| Zero Linden: | the cap server just looks up to see if there is any associated internal URL | |
| Tao Takashi: | so the cap server is a proxy then? | |
| Zero Linden: | and if so, just proxy's the request | |
| Zero Linden: | YES | |
| Saijanai Kuhn: | right now its just an array of keys | |
| Zero Linden: | Indeed - it is verysimple code - which is nice for something that is central t the security of the system | |
| Tao Takashi: | not sure I'd rather would like a cap per "module" not per function | |
| Zero Linden: | So, let's take the inventory item request | |
| Zero Linden: | example | |
| Zero Linden: | The viewer wants information about inveotyr item 443 | |
| Zero Linden: | we'll assume it has a capability to the inventory system, say http://{inv-cap} | |
| Zero Linden: | There are three ways one could design this: | |
| Tao Takashi: | so capabilities are always complete URLs I assume | |
| Zero Linden: | let the viewer invoke GET on http://{inv-cap}/item/443 | |
| Saijanai Kuhn: | https://url:port/cap/UUID | |
| Saijanai Kuhn: | so youre going with http now? | |
| Zero Linden: | let the viewer POST to http://{inv-cap} with a body of something like { verb: get-item, item: 443 } | |
| Zero Linden: | oh -sorry - ALL CAPS ARE HTTPS | |
| Zero Linden: | (caps intentional) | |
| Zero Linden: | :-) | |
| Goldie Katsu sighs in relief | ||
| Zha Ewry: | Have to be, or it is Man in the middle vulnerable | |
| Zero Linden: | And lord knows we want to stick it to the Man! | |
| Tao Takashi likes GET more | ||
| Zero Linden: | he he | |
| Zha Ewry: | Or at least keep the Man out of the middle | |
| Tao Takashi: | more natural IMHO | |
| Zero Linden: | Okay, so, the thrid way is a bit subtle: | |
| Zero Linden: | POST to http://{inv-cap} with a body of { item: 443 } | |
| Goldie Katsu: | just one question (which I probably should have asked a while ago) is there a way that the client knows the cap server is legit and not an imposter? | |
| Zero Linden: | and have that return a cap just to item 443: https://{cap-inv-443} | |
| Zero Linden: | NOW we can do REST on THAT cap doing GET and PUT and DELETE etc | |
| Ahzzmandius Werribee: | Goldie SSL certificate chain | |
| Tao Takashi: | but you have 2 requests all the time | |
| Zero Linden: | Goldie - it has to do with that initial log in - it has to be over HTTPS too, and | |
| Zha Ewry: | Right.. but.. that's expensive, having a cap per item we touch | |
| Neas Bade: | um, why would you do item 3 | |
| Zero Linden: | the viewer better check the certs | |
| Goldie Katsu: | ok...and the client id is validated how? | |
| Tao Takashi: | maybe for putting an object | |
| Goldie Katsu: | (Do we have bidirecitonal verification or can I spoof your client?) | |
| Tao Takashi: | for PUT you might eventually first get a URL anyway | |
| Zero Linden: | Right now, in the current SL viewer - the login servers have SSL certs traceable to a Root CA | |
| Neas Bade: | it really seems like you break a lot of the natural flow by not going with approach 1 | |
| Tao Takashi: | I am definitely for option 1 | |
| Tao Takashi: | as we do GET something | |
| Neas Bade: | agreed | |
| Zero Linden: | and the capability servers have a SSL cert traceable to a CA whos cert is in the viewer and the viewer insists matches | |
| Ahzzmandius Werribee: | option 1 also seems more apropriate to me. | |
| Zero Linden: | So - we are all agreed that option 2 is poor | |
| Ahzzmandius Werribee: | yep | |
| Zero Linden: | Good - internally, over tha last year | |
| Tao Takashi: | I don't see the benefit with 2 | |
| Neas Bade: | yes, option 2 is poor and confusing | |
| Zero Linden: | we've been between 1 and 3 | |
| Zha Ewry: | 1 is slightly soapish.. but simple | |
| Tao Takashi: | I am all for simple ;-) | |
| Zha Ewry is trying very hard to avoid soapish | ||
| Zero Linden: | we always thought we'd do 1, but we kep't getting by with 3 | |
| Tao Takashi: | 3 might get expensive | |
| Zha Ewry: | Parsing headers it expensive | |
| Zero Linden: | Now, 3 is the classic capability paradigm | |
| Zero Linden: | The pure caps folks wouldn't dreamof any other way | |
| Zha Ewry: | Verbs in headers.. even good ones.. is no really REST | |
| Neas Bade: | Zha: why do you think option 1 is soapy? | |
| Zero Linden: | because in 1, you offer a single cap, and it supports a huge set of functionality | |
| Zero Linden: | of course, practically, we recognize it is all a continuum: | |
| Zha Ewry: | Not quite so much soapy.. as less RESTy | |
| Zero Linden: | most systems on the internet to day, your session cookie is a single capability giving you ALL access | |
| Tao Takashi: | why is it less RESTy then? :) | |
| Saijanai Kuhn: | 1 seems worth doing for a CAP that returns [possibly] multiple caps. The seed-cap and the like | |
| Zha Ewry: | As soon as the verb isn't one of the big four.. but.. an operation.. and the asset.. is not mewrely get/put/post/delete It get nervous making | |
| Tao Takashi: | but isn't the verb GET here? | |
| Zero Linden: | Where as a capability to post a comment (say) is still a cpaability of a range of different operations - like posting "I like it" vs. posting "yuck" | |
| Neas Bade: | yeh. I'm confused by your comments zha | |
| Tao Takashi: | maybe you mean #2? | |
| Saijanai Kuhn: | so its https://{CAP} POST key1, key2, key3, etc | |
| Zero Linden: | in other words if the function takes arguemnts, it is always a range of cuntionality | |
| Saijanai Kuhn: | and you get back the standard dictionary as you oo know of key1=CAP1, etc | |
| Morgaine Dinova: | Sai has copyright on that word | |
| Zero Linden: | So, back to 3 vs. 1 | |
| Neas Bade: | right, but one of the key differences is that GET https://{cap-url}/item/431 is fundamentally cachable by url | |
| Zero Linden: | The problem with 1 is one of security | |
| Zero Linden: | it was really easy to simple substitute the internal URL during the proxy | |
| Day Oh: | But wait, aren't there types of data that can't go in a URI | |
| Zero Linden: | whereas, picking off the variable part of the invoking URL and tacking that on to the end of the matched internal URL | |
| Zha Ewry: | GET is.. but | |
| Zero Linden: | was full of pitfalls | |
| Zha Ewry: | Are we still pulling open the header to konw what we are doing? | |
| Zha Ewry: | REST reissts that | |
| Tao Takashi: | I would actually simply map that rest of the URL to my object tree | |
| Zero Linden: | consider https://{inv-cap}/../../money/add-funds | |
| Tao Takashi: | (should I do it with Zope) | |
| Zero Linden: | see,you have to very carefully sanitize the path fragments | |
| Zero Linden: | and the there are arguemtns | |
| Zero Linden: | whereas, if you make a clean substitution here - internal for external - | |
| Zero Linden: | THEN, the internal service has a clear security policy: | |
| Zero Linden: | "trust everything in the URL, as it game from the original capability grantor; trust nothing in the body as it game from the invoker" | |
| Zha Ewry nods | ||
| Ahzzmandius Werribee: | zero, good point. | |
| Zha Ewry: | Also.. the URL is easy to redirect on. without parsing the whole message | |
| Tao Takashi: | good point but IMHO still expensive ;-) | |
| Zha Ewry: | The body.. you have to open up the XML genie | |
| Zero Linden: | So now, during say upload, the sim can grant a cap to the internal URL: http://localhost:12035/asset/upload/script?agent=xxxx&item=yyy | |
| Zero Linden: | and the code at /asset/upload/script | |
| Neas Bade: | that still smells funny to me | |
| Zero Linden: | can trust with certainty who this upload is for | |
| Tao Takashi: | looks not that RESTy internally ;-) | |
| Zero Linden: | well - no, it is still a PUT (in this case) all the way: PUT from the viewer to the cap, proxy'd to a PUT to that internal URL | |
| Tao Takashi: | but it could be /user/<agent>/inventory/<pathtoscript>/<item> (via PUT) | |
| Saijanai Kuhn: | Would it be possible to have paths be abreviations to collections of services? | |
| Zero Linden: | Actually, REST always allows the function at the end of the URL to use the path of the URL as a function input | |
| Neas Bade: | wait a sec. the ../ stuff is just server parsed. There is no reason that .. in a url means go up | |
| Zero Linden: | and REST, or HTTP, doesn't care a wit if it is in the path or the query args | |
| Zero Linden: | Neas - well yes and no | |
| Tao Takashi: | I thought that was one of the ideas but I still need to look into the REST details | |
| Neas Bade: | the money counter example bothers me as a bigger fundamental issue | |
| Zero Linden: | yes it does, but | |
| Neas Bade: | "trust the url" seems like a bad design point | |
| Zero Linden: | acutally, the URI spec DOES give meaning to .. in the context of URI schems that are path based | |
| Neas Bade: | I think it will lead to trouble | |
| Zero Linden: | AND most server frameworks will interpret it | |
| Zero Linden: | since the caps system doesn't want to make assumptions about the system implementing the internal URLs, | |
| Zero Linden: | it would have to be aware and filter such thigns | |
| Tao Takashi: | if I'd do that in Zope and we get a .. it would actually go up but security checks will still kick in and the cap object in the middle might prevent going further up | |
| Tao Takashi: | but it would mean that you have additional checks in there | |
| Zha Ewry: | Ouch. .. is evil | |
| Zero Linden: | well sure, But we want to make sure, at least here in LL, that using off the shelf things like Apache is easy to do | |
| Zero Linden: | SO - no .. | |
| Tao Takashi: | which not every system has or wants to implement | |
| Neas Bade: | a straight up reject of urls with .. would be better | |
| Neas Bade: | which you could do with a mod_rewrite rule very easily | |
| Zero Linden: | it is even more evil, Zha, when you look at the the spec says about things like http://foo.com/.. and http://foo.com/aa/bb/../../../cc | |
| Tao Takashi: | you can also prevent in apache to go further up with mod_rewrite I'd guess ;-) | |
| Zero Linden: | Neas - and then ther eis the whole issue of safely merging query args.... | |
| Zero Linden: | So - for the first caps server at LL, a year ago, we just said "eh, later...." | |
| Zero Linden: | and have been happily working with style 3 caps for a very long time | |
| Zero Linden: | so far, it has been just fine | |
| Zha Ewry: | It takes you places. which are relaly bad, Zero. I've looked at that.. and a few other notations.. and.. because they aren't widely used. | |
| Zha Ewry: | How much do you want to bet many of them are handled wrong in various tools? | |
| Zero Linden: | Zha - oh, I'm sure they are! | |
| Zero Linden: | As for caps and REST | |
| Zero Linden: | here is the crux of the issue | |
| Zero Linden: | REST explictly says that there is no inherit relation between http://foo.com/alpha and http://foo.com/alpha/beta | |
| Zero Linden: | they are just two different resource names, | |
| Zero Linden: | In general, you want a CAP to represent a bounded, set of functionality | |
| Zha Ewry: | Right. Not allowed to assume containment | |
| Zero Linden: | So, if a single CAP, say {inv-cap} is to offer access to two or more inventory items | |
| Tao Takashi: | REST might say that but humans might think otherwise ;-) | |
| Zero Linden: | there isn't really a REST argument to say that https://{inv-cap}/443 and https://{inv-cap}/981 | |
| Zero Linden: | is better than POST to https:{inv-cap} with { item: 443 } | |
| Neas Bade: | actually, not true | |
| Zha Ewry sighs | ||
| Zha Ewry: | The lack of containment.. in REST.. is to avoid.. a bunch of twisty assumptions | |
| Zha Ewry: | But.. In this case.. wow. does it get in the way | |
| Neas Bade: | because I can much more easily build a spreader around the url path | |
| Zero Linden: | and having that return a CAP that you can then GET/PUT/POST to | |
| Ahzzmandius Werribee: | it's starting to sound like using data within the URL is something that we want to avoid. 8-( | |
| Zero Linden: | Neas - in so far as you only have one axis to "drill down on" and so it can be made more generic? | |
| Tao Takashi: | so according to wikipedia POST stands for Create in CRUD | |
| Tao Takashi: | is this wrong? | |
| Vicero Lambert thinks going back tp punchcards would be good :) | ||
| Vicero Lambert: | -to | |
| Wyn Galbraith has some of those somewhere, unused. | ||
| Zero Linden: | Tao - refernece? | |
| Zero Linden: | I don't know what CRUD is (well, other than my old code when I look at it a year later...) | |
| Tao Takashi: | http://en.wikipedia.org/wiki/Representational_State_Transfer | |
| Tao Takashi: | Create, Retrieve, Update, Delete | |
| Tao Takashi: | or Read I guess | |
| Tao Takashi: | the 4 basic db operations | |
| Zero Linden: | ah - that page says that it is often "compared with CRUD", not that it is defined by CRUD | |
| Zero Linden: | and no, I think the comparison, especially with respect to POST, is poor | |
| Tao Takashi: | maybe I should read Roy's chapter on it | |
| Zero Linden: | Indeed | |
| Zero Linden: | I should too | |
| Tao Takashi: | but for now for me it gets more and more blurry what REST actually is and why it is good ;-) | |
| Zero Linden: | Maybe we should get Roy to contribute or at least come to one of these! | |
| Neas Bade: | the O'Reilly book on REST is *very* good | |
| Zero Linden ponders that | ||
| Zha Ewry: | The basic things about rest are that it works well, with cache | |
| Tao Takashi: | except it adds a lot to our discussion :) | |
| Neas Bade: | it just came out in May | |
| Zha Ewry: | and with scale out, in general. | |
| Zero Linden: | you mean "RESTful services" | |
| Sammy Grigges: | hi guys | |
| Zero Linden: | ? | |
| Tao Takashi: | that POST would not work that good with a cache | |
| Zero Linden: | okay - well, it is now 2pm | |
| Neas Bade: | zero, yeh | |
| Zero Linden: | and I've got to go | |
| Ahzzmandius Werribee: | :-) | |
| Zero Linden: | Neas - yes it is very nice | |
| Vicero Lambert: | kk ttyl zero | |
| Neas Bade: | it concerns me quite a bit that an asset get is doing to get done with a POST | |
| Wyn Galbraith: | Thanks Zero. | |
| Zero Linden: | I'm going to take this discussion as mandate that the capabilities page should be the next one for me to flush out | |
| Tao Takashi: | Neas: I guess you need to forget all your implied meanings into those verbs ;-) | |
| Wyn Galbraith has lots to think about. | ||
| Malburns Writer: | tks zero | |
| Zero Linden: | and we'll get to login on Thursday | |
| Rex Cronon: | bye zero | |
| Tao Takashi: | thanks Zero | |