|
| 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
|
