User:Zero Linden/Office Hours/2007 Nov 27
Jump to navigation
Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
| 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 | |