User:Zero Linden/Office Hours/2008 July 22

• [13:04] Rex Cronon: hello everybody
• [13:04] Orion Raymaker: hi
• [13:04] Amigo Draken: hi
• [13:04] Zha Ewry: watches the cloud of OpenSimers arrive
• [13:04] G2 Proto:  :)
• [13:04] Rex Cronon: hiii...
• [13:04] Zero Linden: "here we come...."
• [13:04] Zero Linden: "Walking down the grid..."
• [13:05] Zero Linden: "Get the funniest looks from..."
• [13:05] Tree Kyomoon: /everyone you meet?
• [13:05] Zero Linden: oh, I don't know....
• [13:05] sapherstine Burnstein: hello
• [13:05] Julie Wasserstrom: "hey hey w're the avvies!"
• [13:05] Orion Raymaker: the monkeys?
• [13:05] Rex Cronon: hi
• [13:05] Zha Ewry: We're the rtuthies?
• [13:05] Orion Raymaker: lol
• [13:05] Tree Kyomoon: can one "avvie around" ?
• [13:05] Whump Linden: Sorry, Saij, didn't meen to land in your lap.
• [13:06] JayR Cela: hi Rex :_)
• [13:06] JayR Cela: hello everyone
• [13:06] Rex Cronon: hi jayr
• [13:06] G2 Proto: hey!
• [13:06] Julie Wasserstrom: aww Whump that is cute - the little Gridnaut that could :)
• [13:06] Zero Linden: Tree - my son this weekend starting talking about Second Life and "remember when you were taking with that skeleton?"
• [13:06] G2 Proto: tiny avies scare me
• [13:06] Saijanai Kuhn: I gotta remember to get map ccordinates BEFORE I sit down...
• [13:06] Tree Kyomoon: is reading an interesting article about "Chorus" a company that saved 400,000 a year by letting everyone work at home
• [13:06] Zero Linden: You've made a lasting impression!
• [13:07] Zha Ewry: looks for her pink elepghant tiny ave folder
• [13:07] G2 Proto: lol
• [13:08] sapherstine Burnstein: i apllogise for interupting
• [13:08] Zero Linden: well all - it is another lovely Summer day.... what's on for the Agenda?
• [13:08] Tree Kyomoon: hey thats good to hear zero! your son is clearly a cultured upstanding young lad
• [13:08] Zero Linden: Tree - either that - or he just likes scary things
• [13:09] Saijanai Kuhn: Tess talking about "account maintenance and how that fits into the protoco
• [13:09] Tess Linden: I'd like to talk about account maintenance and how that fits into the protocol
• [13:09] Saijanai Kuhn: told ya
• [13:09] Tree Kyomoon: it is scary to think...a skeleton is hiding inside every one of us
• [13:09] Tree Kyomoon: and if you ever see it, you are probably in trouble
• [13:09] Tess Linden: hehe
• [13:09] Zero Linden: okay - 1) Account Maintence
• [13:10] paulie Femto: whoa. :)
• [13:10] sapherstine Burnstein: eyah and if it leaves with you standing there you know your in trouble
• [13:10] Zero Linden: well - take it away, Tess
• [13:11] Zero Linden: what *is* all this we hear about account maintenence?
• [13:11] Tao Takashi: Hi
• [13:11] Rex Cronon: hi
• [13:11] Dahlia Trimble: Hi :)
• [13:11] G2 Proto:  :)
• [13:11] JayR Cela: :_)
• [13:11] Effie's HUD: 0.8 [script:Visitors 0.1]: Script run-time error
• [13:11] Effie's HUD: 0.8 [script:Visitors 0.1]: Stack-Heap Collision
• [13:12] Zha Ewry: Change the oil every 3,000 miles, and make sure you have a good spare tire?
• [13:12] Orion Raymaker: lol
• [13:12] Tess Linden: while we were working on login as preparation for the Beta, we realized that account maintenance in the old login needs to fit into the protocol somehow
• [13:12] Zha Ewry: oooh
• [13:12] Tess Linden: account maintenance is operations on your account that has to be done before you log in
• [13:13] Zha Ewry: You mean that annoying "hang on we're dinking with your account messsge"
• [13:13] Adam Zaius: I'd put that as a generalised status message personally
• [13:13] Tess Linden: yep. it's the obscure thing we call "transforms"
• [13:13] Adam Zaius: Something like a 503 Temporarily Unavailible
• [13:13] Zha Ewry: its a 40x
• [13:13] Zha Ewry: or a 50x,
• [13:13] Zha Ewry: Yeah, 503
• [13:13] Tree Kyomoon: is that the one that holds you back if you need to be logged out after you crashed?
• [13:13] Zha Ewry: No, its the one when they do things to your underling account which take time
• [13:13] Tess Linden: Tree: nope
• [13:13] Zero Linden: well - I don't think we want it to be a 5xx - server problem
• [13:14] Zha Ewry: the 5 minute time out kicks you out all the way
• [13:14] Zha Ewry: "Come back later"
• [13:14] Zero Linden: oh, no
• [13:14] Zha Ewry: this is "We're busy"
• [13:14] Zero Linden: this isn't the "You can't log in until xx:xx"
• [13:14] Zha Ewry: "But we'll be able to handle you again soon"
• [13:14] Zero Linden: this happens as a normal part of the login - the progress bar
• [13:14] Zero Linden: just goes slower
• [13:14] Zha Ewry: A lot slower
• [13:14] Adam Zaius: That's still within the realm of a "Busy, try again later"
• [13:14] Zha Ewry: Well, it does complete
• [13:15] Zha Ewry: you don't need to retry
• [13:15] Zero Linden: this is "You are auth'd, and all is cool... we just need to run some SQL over your account tables and you can't be in world until we do..."
• [13:15] Gulliver Linden: tess: are they still used for a lot? and... are they something that should be exposed by the protocol?
• [13:15] Tree Kyomoon: is that specific to the region or ?
• [13:15] Zero Linden: "It's be ready in 5.... 4.... 3... 2... 1..... "
• [13:15] Zero Linden: and then login goes on
• [13:15] Zha Ewry: Hrmp
• [13:15] Zha Ewry: Its advisory status
• [13:15] Gulliver Linden: i.e., does the person logging in care that they are running? except other than maybe to get a countdown on when they will complete?
• [13:15] Zha Ewry: which doesn't really fal into the HTTP rteturn codes
• [13:15] Tess Linden: Gulliver: as the grid grows larger, there will always be maintenance on pieces of the grid that we're growing
• [13:16] Zero Linden: They are used when an agent domain needs to change or update something in the database for all accounts and it would just kill things for too long if we took
• [13:16] Zero Linden: down the system and did it to all accounts and then came back up
• [13:16] Tess Linden: Gulliver: yes, because they cannot log in while it is running
• [13:16] Zero Linden: so we do it on demand, as the accounts log in
• [13:16] Zha Ewry: well, wait
• [13:16] Zha Ewry: If they can log in, its just advisory
• [13:16] Julie Wasserstrom: Is there an issue in hiding this from the user - possibly with a silent retry rather than a flat-out reject?
• [13:16] Gulliver Linden: listens
• [13:16] Zha Ewry: if they can't its a 5xx
• [13:17] Zero Linden: Right so there are two things going here: advisory status of how far along the "login path" you are, and a state that the agent account is in
• [13:17] Zha Ewry: or is there a set of message sin the current protofocl?
• [13:17] Zero Linden: the state diagram might be like:
• [13:17] Adam Zaius: 503 can still return content.
• [13:17] Tess Linden: the only thing they can definitely do is authenticate. After that, all bets are off because we could be migrating you to a new database
• [13:17] Adam Zaius: There's nothing stopping us sending that header, then sending the adivsory as the comment?
• [13:17] Zha Ewry: And having the client, retry?
• [13:18] Adam Zaius: Makes sense to me?
• [13:18] Julie Wasserstrom: Yes Zha - or make it up to the user
• [13:18] Tao Takashi: what would be an alternative?
• [13:18] Zero Linden: (0) unknown ---> (1) auth'd ---> (2) connecting to AD ---> (3) on-line in the AD
• [13:18] Zha Ewry: In fact, its kind of nice, to be able to sit in the 50X loop, as it lets you a) quit neatly, knowing why
• [13:19] Zha Ewry: and b) update the status, as it progresses
• [13:19] Zha Ewry: Http, working as designed again? what, who let it do that?
• [13:19] A group: member named cypress Rosewood gave you Bubastus - Temple of Bast, Lyre (56, 64, 79).
• [13:19] Julie Wasserstrom: Is this possible in spite of the statelessness?
• [13:20] Gulliver Linden: one would have to repost their credentials
• [13:20] Zha Ewry: Hmm.
• [13:20] FWord Utorid: is this about how we might be able to log in an avatar without having to have it in a sim?
• [13:20] Zero Linden: In the current protocol what happens is that we return it as a sort of "semi-failure" case to the viewer's HTTP request to login....
• [13:21] Gulliver Linden: and the viewer retries?
• [13:21] Zero Linden: the failure (still a 200 status, I think) is indicated in the payload as a reason - and in this case is something like
• [13:21] Tess Linden: FWord: even less than that. withouti t having to be 'online' in the agent domain
• [13:21] Zero Linden: "please login again, but to this new login URL"
• [13:21] Zero Linden: "oh and everything is okay, and you are 2/7 the way through...."
• [13:22] FWord Utorid: tess: i am working on a program that would be better if there wasn't an avatar visible, but IMs could still be processed... [1]
• [13:22] Zero Linden: FWord - logging into the Agent Domain doesn't require teleporting into a region at preset
• [13:22] Tao Takashi: sounds like a redirect then
• [13:22] Julie Wasserstrom: My thinking is that eventually the client will evolve to a "connected as much as you can" model
• [13:22] Tao Takashi: but why a different url then?
• [13:23] Zero Linden: Tao - as currently implemented it is very like a redirect
• [13:23] Zero Linden: Tao - because that is how we keep track of the state... it is sort of like an early form of capabilities
• [13:23] Zha Ewry: Ah.. you go from redirect, to redirect, as you progress?
• [13:23] Zha Ewry: wimpers al ittle
• [13:23] Zero Linden: Currently, yes
• [13:23] Tao Takashi: somebody invented cookies and sessions for that ;-)
• [13:24] Effie's HUD: 0.8 [script:Visitors 0.1]: Script run-time error
• [13:24] Effie's HUD: 0.8 [script:Visitors 0.1]: Stack-Heap Collision
• [13:24] Zero Linden: which is why I don't want to repeat that
• [13:24] Tao Takashi: ok
• [13:24] Zero Linden: uh, that was to Zha
• [13:24] FWord Utorid: thanks. i guess i missed the part right after i said why i want that feature :/
• [13:24] Zha Ewry: So, we're calling a cap, and the cap says
• [13:25] Zero Linden: as for cookies and sessions - the reason for not using those is....... global state! Ask anyone who has done a web site with session state that had to scale to more
• than a few servers
• [13:25] FWord Utorid: but basically, for the very reason i just experienced. the viewer crashes on me, and i want to be able to im without the full monty
• [13:25] Zero Linden: sharing sessions state is the bane of the whole system
• [13:25] Zha Ewry: "Not now, but soon"
• [13:25] Tao Takashi: well, you have a state somewhere in your system nevertheless
• [13:25] Zha Ewry: Right
• [13:25] Zha Ewry: No cookies. We're RESTful here
• [13:25] Zha Ewry: You want to be able to drop the next request onto any server in the cluster
• [13:25] Zero Linden: Tao - you do, but it is more distributed with caps....
• [13:26] Gulliver Linden: zero -- what is the alternative to re-requesting (i.e., reacting to a redirect)?
• [13:26] Zero Linden: well - there are pros and cons I suppose
• [13:26] Zero Linden: but ANYWAY ----- yes, FWord - OGP should easily allow a
• [13:26] Zero Linden: client that does IM but not be in-world
• [13:26] Tess Linden: we have some tools to work with, llsd-http/REST, and event-queue for push messages
• [13:26] FWord Utorid: zero, cool. i am ready for it in a couple of days.
• [13:27] Orion Raymaker: lol
• [13:27] couch sit: 1 RED.: Zha Ewry, say '/1 Hide' to hide me, or '/1 Show' to make me show. Or just right-click and sit on me to use me.
• [13:28] Tao Takashi: well, this caps stuff is right now my main problem with imlpementing an agent domain. It does not really fit any web framework
• [13:28] Zero Linden: Gulliver, as Tess said, we could just succeed on the auth, and let the viewer connect to the event queue (on the Agent Domain), and then feed status messages back
• to the viewer that way
• [13:28] Tao Takashi: but anyway, does this need to happen in sending the login data
• [13:28] Tao Takashi: or could this happen as part of some initialize cap or so?
• [13:28] FWord Utorid: i want to use the grid and it's underlying network for other applications without impacting the in-world experience, for other kinds of collaboration tools
• unsuited to the 3d environment, but suited to the login services and IM communication area.
• [13:28] Gulliver Linden: i sort of like that idea, it makes auth simple and self containted.
• [13:29] Tess Linden: for sure, we don't want to grant any capabilities until all maintenance is completed
• [13:29] FWord Utorid: I wonder if there is the possibility for sending other kinds of messages through the infrastructure, underneath the IM system, which basically would allow any kind
• of app to work over SL
• [13:29] Tao Takashi: well, then the 50x loop
• [13:30] Tao Takashi: why do you need state actually? You should have some state which says if maintenance is completed or not
• [13:30] FWord Utorid: basically like CTCP kinda does under IRC, but not in such a way that a viewer would see garbage if it wasn't set up to handle these new message types.
• [13:30] Tess Linden: Tao: the authentication piece of login is pretty modular now, and it doesnt make sense to couple maintenance to "am I authed?"
• [13:30] Gulliver Linden: agrees with tess
• [13:30] Zha Ewry: You can't grant the caps, while you're not up, can you?
• [13:31] Tao Takashi: but doesn't it need to be coupled somewhat? in order to trigger maintenance?
• [13:31] FWord Utorid: secret love messages that only someone with a decoder ring on the other side of the internet could read.
• [13:32] Zero Linden: well - that's the thing, Zha - the agent would be in a state where it could grant some caps (event queue, for example), but not others
• [13:32] Tess Linden: +1 Zha
• [13:32] Zha Ewry: Hmmm
• [13:32] Zero Linden: we'd need a way to indicate - "Okay, go get 'em now..."
• [13:32] Tao Takashi: rhttp comes to mind ;-)
• [13:33] Zha Ewry: I hate to put a lot of extra stuff into wha's 90% a retry loop
• [13:33] Zero Linden: or a way to have the seed cap response say "er, those aren't ready yet... please try again later..."
• [13:33] FWord Utorid: this is probably not technically accurate, but is it possible there could be a kind of agent to agent caps, where both ends could communicate about some sort of an
• llsd data structure and trade them?
• [13:33] Zero Linden: right
• [13:33] Tao Takashi: I am not sure I would put this into a result of trying to obtain a cap from the seedcap
• [13:34] Infinity Linden: but is this something that needs to be at the app layer? does HTTP have a result code of "try again later?"
• [13:34] Zero Linden: FWord - one could imagine an Agent Domain offering a service to ferry around LLSD blocks like IMs....
• [13:34] Tao Takashi: somehow this sounds not clean
• [13:34] Zero Linden: but as such, it isn't built
• [13:34] Zha Ewry: those all feel like "resource busy" with a message to me
• [13:34] FWord Utorid: zero, it would be really great. i might be able to use the binary section of the instant messages to send some data, but it would be really cool to have verbose
• exchanges.
• [13:34] Zero Linden: I don't think HTTP has it in the sense we want here: The client app. needs to proceed like things are going well ... not an error condition
• [13:35] Zero Linden: I think all the 5xx really indicate that the server is bork'd in some way - and the client isn't supposed to try again
• [13:35] Zero Linden: FWord - look at the current UDP based message system -- - you'll see "Improved Instante Message" - which is really just that...
• [13:35] Adam Zaius: 302 / Temporary Redirect ?
• [13:35] Zero Linden: IM got reused as a proxy for SO many things
• [13:35] Adam Zaius: (or is that 305?)
• [13:36] Infinity Linden: yeah.. think its 307
• [13:36] Zero Linden: but then you have to deal with what if some intermediate proxy decides to "take care of that for you" by doing the redirect?
• [13:36] Zha Ewry: You always have that worry, al ittle, Zero
• [13:36] Infinity Linden: blergh. yeah... it is in the app domain
• [13:36] Saijanai Kuhn: Stonecuter and I talked about a faux-Peer2Peer cap that could pass messages from avatar to avatar bypassing the standard events system. If messages became complex
• and busy enough, you could upgrade to a true P2P system
• [13:36] Zero Linden: see - would we want the intermediate infrastructure (including the HTTP client lib the viewer uses) to interpret and react to this state? I think not
• [13:36] Zero Linden: as such, I think 200, and a clear response state
• [13:37] Tao Takashi: I really would think the cleanest would be to put it into the login resource which might return some information via some 200 payload
• [13:37] FWord Utorid: zero, i am thinking of things that might need more than the improved im would allow. like a whiteboard system, where multiple parties can paint and so on. that's
• just an example. i want LL to pay for the networking and auth systems for many different apps i have in mind.
• [13:37] Zha Ewry: well, we do and we don't, Zero. If we are saying 'Come back again, shortly" we should be wiling to say it to the whole stack
• [13:37] Tao Takashi: maybe indicating some time it might take and after which the client should try login again
• [13:37] Zha Ewry: No reason to assume its the current client
• [13:37] Infinity Linden: yeah... we should have the app layer be distinct enough that you could substitute a p2p transport if need be... but I dint think we should work on that now
• [13:37] Saijanai Kuhn: FWord, that's where teh faux transits to a true P2P. At most, the protocols should just provide the way to establish the P2p system. They don't define anything
• beyond it
• [13:38] Zero Linden: FWord - try: "I want LL to host the ...." and you might get a better response... :-)
• [13:38] FWord Utorid: zero, i am in sl to have fun, so i say things i would never say in church.
• [13:38] FWord Utorid: but i would put a shiny LL logo on stuff if it wouldn't scare people
• [13:39] Tess Linden: what are the current use cases for 503 errors that says come back later?
• [13:39] Tess Linden: do they apply to our situation?
• [13:39] Zero Linden: Zha - I guess that's the crux - in this case I think the "come back in a few seconds, it is all alright, your almost there, just try again" is
• [13:39] Zero Linden: the wrong message
• [13:39] Tao Takashi: "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server"
• [13:40] Tao Takashi: If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500
• response""
• [13:40] Infinity Linden: 503 has the concept of a Retry-After
• [13:40] Zero Linden: it is more of "you're in! you made it! Now, we're adjusting things, and we're almost done. Please wait for "DONE" before doing more."
• [13:40] Infinity Linden: where you can say.. .come back in N seconds
• [13:40] Tess Linden: the spec doesnt say anything about maintenance
• [13:40] Zha Ewry: Well, for a client, with a user, perhaps
• [13:40] Tao Takashi: that's from [2]
• [13:40] Zha Ewry: For a pprogram.. Hmmm.
• [13:41] Zero Linden: I think you are right, the "You can't log in utnil ..." and the "oooops overloaded, try again soon" should be 5xx level messages
• [13:41] Gulliver Linden: this seems more like a 307, or a 200 with some app-layer directive inside
• [13:41] Harleen Gretzky: Does the same sort of thing happen now when you log onto the beta grid?
• [13:41] Infinity Linden: but using the http layer to convey info about the app state seems wrong. _insert zero's concerns re web caches_
• [13:41] Tess Linden: theres a Retry-After field you can indicate
• [13:41] Zero Linden: Yes, Harleen - exactly - first login to a beta grid triggers a transform
• [13:41] Gulliver Linden: Infiinity: so 200 with app-layer directive?
• [13:41] Infinity Linden: that's what I was thinking
• [13:42] Tao Takashi: I would also go with the 200
• [13:42] Gulliver Linden: "auth succeeded, maintanence commencing, go here to get maintance status and/or caps..."
• [13:42] Infinity Linden: or "teleport agent to future"
• [13:43] FWord Utorid: i was at prospero's talk about that. teleporting to the future is really slow.
• [13:43] Tao Takashi: and needs lots of bandwidth
• [13:43] Zero Linden: always goes with lots of bandwidth
• [13:43] Tess Linden: just a thought...
• [13:44] Infinity Linden: and for my money, HTTP is a resource transport
• [13:44] Gulliver Linden: tess: what is "the system" here, in contrast to "the app"?
• [13:44] Tree Kyomoon: it takes 1 second per second
• [13:44] Tao Takashi: well, so far I know no social network which delays your login
• [13:44] Infinity Linden: well... when facebook is down for maintainance, they delay your login
• [13:44] Tree Kyomoon: facebook delays my login significantly
• [13:44] Tao Takashi: so I would first check if this is really used before we maybe can contact w3c and apply for changing HTTP :)
• [13:44] Infinity Linden: (in the sense that you have to manually try it later)
• [13:45] Tess Linden: is this really application state? or system state? and if we're designing the next HTTP for virtual worlds, then should there be some connection?
• [13:45] Zero Linden: with all due respect - most social networks are either web apps or IM systems - and the entire agent state of the later is... perhaps your e-mail address
• [13:45] Tree Kyomoon: that too
• [13:45] FWord Utorid: zero: or the app's server side session, foshoa
• [13:45] Infinity Linden: wait... are we really going to add virtual worlds bits to HTTP?
• [13:46] Zha Ewry: I don't think we want to add VW speciif c stuff to http, no
• [13:46] Tao Takashi: for now I would stay with a message in some response payload with 200
• [13:46] Tree Kyomoon: that would be good...I keep asking for a mini SL viewer I can embed in an html page
• [13:46] Tao Takashi: I aldo don't think we should invent our own http status codes
• [13:46] FWord Utorid: isn't there enough flexibility in the HTTP Headers to permit the information to extend it?
• [13:46] Zero Linden: What? no "Avatar-attachements: " header? no "666 Griefer" status codes?
• [13:47] Infinity Linden: HTTP is a transport protocol
• [13:47] Tess Linden: would it make more sense to grant the cap, and have the cap give back a 503 until maintenance is finished?
• [13:47] Gulliver Linden: maybe we should add 666 Griefer. that one is pretty good.
• [13:47] FWord Utorid: repent!
• [13:47] Tree Kyomoon: wasnt http designed to only transfer hyper text?
• [13:47] Tree Kyomoon: (as opposed to restful text)
• [13:48] Infinity Linden: http was designed?
• [13:48] Tree Kyomoon: he hheh
• [13:48] Tao Takashi: I don't like the idea to put this into the seed cap response
• [13:48] Infinity Linden: i'm just thinking it lays above the "transport"
• [13:48] Gulliver Linden: more that the 200 with app-layer payload
• [13:48] Tree Kyomoon: infinity depends on your world view...was there an intelligent designer behind http or did it evolve?
• [13:48] Tao Takashi: so you mean I try to get a cap from the seed cap and get back a 503 ?
• [13:48] Infinity Linden: does it make sense to add an attribute to any resource that stipulates it's validity dates?
• [13:49] Tess Linden: imagines cooking her toast in her toilet on the kitchen counter
• [13:49] Gulliver Linden: i like it because, if you had a system that did not do maintenacne, and then you had to make it support maintenance... that seems like what you would do.
• [13:49] Zha Ewry: You'd end up havign to make all the possible handlers of your downstream caps handle this
• [13:49] Zero Linden: Tess that strikes me as hard to do --- there might be hundreds of caps that the viewer wants to get from the agent domain (okay, tens...) --- and to have each of
• them have to check on invocation to see if the maintenence is done seems likely to be hard
• [13:49] FWord Utorid: tess, where do you come up with such off the wall ideas? you don't take the toilet into the kitchen, you take the kitchen to the toilet. it's more efficient, one
• stop shopping :O
• [13:49] Tao Takashi: this would mean I would have to change all my cap handling code for a case which should only happen on login time
• [13:49] Tess Linden: Zha: the client should be able to handle errors from invoking caps anyway
• [13:49] Tree Kyomoon: maintainance or not
• [13:49] Zha Ewry: No, it's the servers, that's painful
• [13:50] Infinity Linden: so if you wanted to transport SL messages across a P2P network, you would be hosed if it was HTTP specific
• [13:50] Gulliver Linden: tess -- actually... that makes a lot of sense to me.
• [13:50] Zha Ewry: The servers downstream form the auht grant
• [13:50] Tree Kyomoon: shouldnt caps be handled per request?
• [13:50] Tess Linden: the cap server can store that state of whether maintenance is being done, and not proxy?
• [13:50] Zha Ewry: Assuming it's one server
• [13:50] FWord Utorid: tree, just because something is designed to do only one thing doesn't mean you can't reengineer it to do another. if you wanted to, you could turn your toilet into
• a toaster. it's not a good idea, but you could do it :)
• [13:50] Zha Ewry: There's no structural reason, the caps cant end up being to a dozen servers
• [13:50] Tao Takashi: for the cap server I was hoping for a simple plugin server to use
• [13:50] Gulliver Linden: what if auth always returns 1 cap, and then that cap either returns more caps (maintenance is done), or 503 (not done)
• [13:51] Tao Takashi: because if you want people to implement it this stuff needs to be as simple as possible
• [13:51] Zero Linden: well - and furthemore - it strikes me as an odd place for status functionality - in the caps server
• [13:51] Tree Kyomoon: depends on how modular your toilet is, and if it is IEEE compliant
• [13:51] Gulliver Linden: instead of auth returning "more caps" directly
• [13:51] Tao Takashi: and caps in itself are not. And if you then have to implement your own cap server to handle such things that would be painful IMHO
• [13:51] Zero Linden: Remember - the advantage of caps is the separation of authorization to do a function from implementting the function
• [13:52] Zero Linden: you can put the authorization in the one common place (as it is often based on the same criteria for collections of functions)
• [13:52] Zero Linden: and not have to make any decisions in the function implementation - just do it
• [13:52] Tree Kyomoon: so then you should handle the caps init at login and not have to deal with it again?
• [13:52] Zha Ewry: If you're not careful, you'll end up with 1/2 yoru caps 50Xing and the rest, returning normally,w hicl.. should be handled by a conumser, but ick
• [13:52] FWord Utorid: ok, so one should not use caps to do things, one should use it like login. does it tell you where to get services it authorizes?
• [13:52] Tess Linden: yea... zero the caps server is the wrong place
• [13:52] Tao Takashi: Zero: I see this as disadvantage ;-)
• [13:52] Gulliver Linden: "post to auth, get back seed, GET seed, get 503, retry seed, get more caps"
• [13:52] Tao Takashi: but anyway :)
• [13:52] Zero Linden: so the seed cap handler is the right place to put in the "nope, you can't do this 'cuase your account is being fiddled with --- so no cap Foo for you!"
• [13:52] Tree Kyomoon: the cap nazi?
• [13:53] Tao Takashi: I still think it's the login service
• [13:53] Tao Takashi: it does some preparation before you can login
• [13:53] Tao Takashi: having it in the cap handler would also mean that it needs some callback
• [13:53] Tao Takashi: to inform the rest of the system of this problem
• [13:54] Tess Linden: how should the protocol look?
• [13:54] FWord Utorid: if you have the right authorization, you should always be able to login. preparation should happen before you can do stuff but after login. like, right now, i
• should get past the login screen before my clothes are downloaded and a region is selected. like, a waiting room.
• [13:54] Tao Takashi: or the function invoking my cap function would need to handle this
• [13:54] Tess Linden: right now its: {'caps': {'rez_avatar/place':____, 'legacy_login':____}}
• [13:55] Zha Ewry: The more I look at this, if we need the step
• [13:55] Zha Ewry: it needs to be in the login process, saddly
• [13:55] Zha Ewry: You don't want it in the caps ta all
• [13:55] Tao Takashi: in a client I would like to only handle this situation once, hopefully at the beginning
• [13:55] Zha Ewry: and.. whiler its tempting to handle it in a status
• [13:55] Tao Takashi: before I get into my main loop
• [13:55] Tree Kyomoon: mabey we can make it replace something else in the login process
• [13:55] Zha Ewry: I think you're really looking to do it early
• [13:55] Zha Ewry: and as a very special case
• [13:56] Tao Takashi: maybe it can be a cap before the seed cap?
• [13:56] Zero Linden: so - prior to establishing the event queue?
• [13:56] Zero Linden: Tao - meta-cap?
• [13:56] Tao Takashi: and you call this cap as often before it returns the seed cap
• [13:56] Zero Linden: chicken-and-egg-cap?
• [13:56] Tao Takashi: that's not a meta cap
• [13:56] Zero Linden: proto-cap
• [13:56] FWord Utorid: most people are horribly impatient. the sooner you get them through bottlenecks the less likely they will be to feel frustrated.
• [13:56] Zha Ewry: Libery cap
• [13:56] Tree Kyomoon: put-it-in-your-cap?
• [13:56] Tao Takashi: maybe a proto-cap :)
• [13:56] Zero Linden: protozoa-cap!!!!!
• [13:57] Tao Takashi: probably a tao of caps
• [13:57] Tree Kyomoon: cap-y-bera
• [13:57] FWord Utorid: resists the urge to de-cap-itate the conversation
• [13:57] Zero Linden: was once a beta-tester for a digital music synthesizer called the capybara....
• [13:57] Tao Takashi: login returns {'proto-cap': http:/cdjhbcdjhscbscjhbsd}, you call it, get back some payload which tells you the status and try as long as it needs to get some
• {'seed_cap': 'jhdbdhjbdcjbsd'} back
• [13:57] Tao Takashi: then as it's written
• [13:58] Gulliver Linden: well known login url returns error or seed cap, seep returns 503 or more caps?
• [13:58] Zero Linden: okay - so the big take-aways I got from this were
• [13:58] Tao Takashi: actually it's the maintenance cap ;-)
• [13:58] Zero Linden: 1) this isn't a transport level status, so keep it out of HTTP status and headers
• [13:59] Tree Kyomoon: [3]
• [13:59] FWord Utorid: there should be two main caps, which branch out to infinitely more caps. if you have cap B, you request 12 more caps, which in turn, request 12 more each.
• [13:59] Gulliver Linden: seems right...
• [13:59] Gulliver Linden: (zero)
• [13:59] Zero Linden: 2) this should really be over and dealt with once - so it is okay to extend the auth part of the protocol to handle it and not worry about creating generic
• facilities in caps or agent domain states to handle it
• [14:00] Zero Linden: I think at this point perhaps Tess and Infinity can put together a concrete proposal
• [14:00] Zero Linden: and - oh my - look at the time!
• [14:00] Zero Linden: soon to be my all time favorite IBM computer....
• [14:00] Tao Takashi: yeah, 10 hours of contant SL office hours and meetups...
• [14:00] Gulliver Linden: well, any service that can't run until it does some long M task, can always work by this kind of 1-more step indirection.
• [14:00] Zero Linden: wait for it......
• [14:01] Zero Linden: soon...
• [14:01] Tao Takashi: this at least is how it feels
• [14:01] Tree Kyomoon: I guess that caps off this meeting!
• [14:01] Zero Linden: there it is! IBM1401 -
• [14:01] Zero Linden: thanks all
• [14:01] FWord Utorid: make it work so people can complain
• [14:01] Tao Takashi: use auth headers ;-)
• [14:01] Gulliver Linden: Tree: groan.
• [14:01] Zero Linden: I'm off to a zillion more things!
• [14:01] Rex Cronon: bye zero
• [14:01] Gulliver Linden: bye zero.
• [14:01] FWord Utorid: use beer to fuel it
• [14:01] Orion Raymaker: ty all :)
• [14:01] Zero Linden: thanks for all coming
• [14:01] Tree Kyomoon: sorry it was out there...
• [14:01] FWord Utorid: thanks zero ;)
• [14:01] Rex Cronon: bye everybody
• [14:01] Tess Linden: bye zero!
• [14:01] Tao Takashi: you can put a proxy in front which checks the auth header and denies requests, seems to be the same like caps just that no extra hop is needed :)
• [14:01] Infinity Linden: d'oh! he escaped!
• [14:01] Saijanai Kuhn: bye all. Tree you putting the transcript online?
• [14:02] Tree Kyomoon: yes I can do it now
• [14:02] Mayumi Fride: bye
• [14:02] Saijanai Kuhn: great. Laters all
• [14:02] Whump Linden: thanks, Tree
• [14:02] Whump Linden: okay... lunch
• [14:02] Gulliver Linden: bye folks...
• [14:02] Whump Linden: or I go into safe mode
• [14:02] Tree Kyomoon:  :)