User:Zero Linden/Office Hours/2007 Dec 13

From Second Life Wiki
Jump to: navigation, search

Transcript of Zero Linden's office hours:

Desu Uriza gave you Al Azem Welcome Back Mary.
Zero Linden: hello hello
Saijanai Kuhn humms "Hail to the Chief"
Tao Takashi: Hello Mistah Linden
Morgaine Dinova: 'Morning Zero :-)
Echo Seigo: hey hey cap'n
Harleen Gretzky: Hi Zero
Feep Larsson: Hey Zero
Jimmer Gabe: helo :)
Arawn Spitteler: His hair is grey
JetZep Zabelin: hi Zero!
Zha Ewry: Morning Zero
Zero Linden: my hair *is* grey
Indya Etchegaray: hello zero
Wyn Galbraith: Morning Zero.
Zero Linden: but this is my Supa'Fly hat!
Rex Cronon: hello zero
Saijanai Kuhn: Good morning teacher!
Wyn Galbraith: It's splended.
Echo Seigo: fuzzies!
Zero Linden: oooooo protocol diagram
Morgaine Dinova: I suspect every Linden's hair got a little greyer over last few days :-(
Candy Durant shouts: Anyone here work for Lindens???
Wyn Galbraith: Is age verification not working correctly yet?
Arawn Spitteler: It works perfectly; anyone who tries it, is obviously under age
Candy Durant shouts: thanks!
Wyn Galbraith: I passed a long time ago, but it shows in my profile not verified, and the webpage doesn't allow you to go through it again.
Zero Linden: Well - on that note: Welcome to my office hours! I'm Zero Linden, and indeed, like all avatars with the last name "Linden", I work for Linden Lab
Echo Seigo: zomg a real linden!!!!!
Echo Seigo: lol
Rex Cronon: is down? i can't connect to it
Wyn Galbraith: I think Candy isn't in range, she shouted.
Zero Linden: As always, the transcript of this hour will be posted to the publick wiki: So speak freely, speak openly
Wyn Galbraith: Works for me Rex.
Rex Cronon: weird
Jimmer Gabe: ehhmmm... well I have a question about porting the viewer to an old but venerable OS...
Tao Takashi: so can somebody explain to me again maybe the benefits of caps instead of sending something in a header? ;-) I had a hard time to explain it to a friend.
Wyn Galbraith: OMG a giant eye!
Indya Etchegaray: when was the last "tweak"?
Jimmer Gabe: i;m not sure if this would be the right place...
Tao Takashi: and I also don't see the benefit when implementing it as I have to check authentication at some point anyway. so for me it mostly looks to be more complex and maybe less fast
Tao Takashi: maybe some usecases would help in which they are useful
Zha Ewry: Zero, can you give a one or two sentance comment on Cory? Any impact at all on the AWG work? (I'd expect not, but hearing it would be nice)
Tao Takashi: (as a sidenote: what's the progress on open sourcing the LL capsserver? :-) )
Tao Takashi: ah, I second that about Cory, I also would like to be sure we don't cancel this whole effort now
Zero Linden: Okay -
Zero Linden: caps is a good topic
Morgaine Dinova: Departure of a CTO must impact on a technical group like AWG, so yes, that would be important.
Tao Takashi: and of course we want gossip ;-)
Zero Linden: Cory is a hard topic
Dr Scofield doubts we'll get that
Morgaine Dinova: I don't want to know about Cory, just about the technical direction.
Zero Linden: well, let's deal with that upfront
Tao Takashi: I also mostly want to know what it means to open source etc. if there's anything changing or not or if that isn't clear yet
Zero Linden: Obviously development is going to feel the impact of Cory's departure.
Zero Linden: However, the studio directors and other leaders within development just spent an entire day offsite
Zero Linden: yesterday to talk about project planning, and goals
Zero Linden: and I can assure you that development is moving forward on all cylinders just as it has been
Tao Takashi: (I also would like some official statement from LL what it does mean for SL as whole btw :-) )
Saijanai Kuhn: we're doomed...
Zero Linden: the group did not decide on any major change of strategy or direction
Wyn Galbraith hadn't heard that news.
Morgaine Dinova: Oh dear
Zero Linden: What I'm trying to convey is that Cory's leaving was not because of some erruptive shift in LL's strategy or direction
Zero Linden: Nor will it cause such an upset.
Tao Takashi: the more instresting it's then what these differences might have been ;-) but anyway, nothing for the public.
Tao Takashi: well, I wouldn't expect SL to go down now anyway.. LL has enough smart people still
Zero Linden: That, I'm afraid in this case, is true.
Zero Linden: Okay - moving on to caps
Zero Linden: I realize that we've talked about caps in the past, but since inside LL we are making such extensive use of them,
Zero Linden: I want to make sure everyone here is really comfortable with them
Squirrel Wood: According to the comments on the official LL blog, there are only idiots working at LL but we all know those posts stating such facts are done by brain amputated individuals who cannot think of anything better to do :p
Tao Takashi: they are done by idiots ;-)
Tao Takashi: (the posts, not the caps)
Zero Linden: Well, and I tend to think of my self as a 'doofus' or 'dolt' more than as an 'idiot'
Zero Linden: :-)
Morgaine Dinova: Not sure I understand how the departure of a CTO (who presumably was *leading* LL's direction) can result in ... no change of direction. ;-)))
Tao Takashi: so my problem in this case is mainly that I have to check permissions now upfront.. and I wonder what the advantage is of doing that
Morgaine Dinova: Don't answer that :-)
Neas Bade: zero, another possibly quick thing, I saw that 1.8.6RC1 was out, and still no -loginuri support in it. Rob asked me to bring it up in a week if there wasn't a change there
Zero Linden: (hmmmm... okay need some more on the CTO topic....)
Tao Takashi: in fact the seed cap thing needs to know quite a lot now or at least needs to ask other components
Zero Linden: So, it is important to understand a little about how LL is run: We don't have a traditional heirarchy
Wyn Galbraith: Doesn't Philip lead the direction of LL more so than a CTO? The CTO would have to be inline with Philip, I would think.
Zero Linden: While Cory as CTO was "head" of engineering, and in a role of leadership
Zero Linden: we have a form of management here that enables the direction to be developed and lead by many people in the organization
Zero Linden: So for example, it isn't the case that Cory's passion for open source was the only reason we were doing open source
Wyn Galbraith breaths a sigh of relief.
Zero Linden: There are many people in engineering who are equally passionate about that direction, and that is the reason it has had any traction
Zero Linden: We are all still here, and our commitment to open source is continuing
Tao Takashi: btw, regarding this topic. Is it clear throughout the company actually what doing AWG means in the end? like people running their own (separate) grids, etc.=
Tao Takashi: ?
Morgaine Dinova: It's an interesting structure, non-hierarchical. I've not come across it before in any company (UK only though).
Zero Linden: Tao - absolutely
Tao Takashi: well, it someday sounded from Robin as she was questioning that a little.. if they just take the tech and do their own stuff, why do it?
Tao Takashi: but I might have misunderstood this
Zero Linden: There is no question that we have to enable other people running parts of the grid
Tao Takashi: yes, but running their own grid?
Saijanai Kuhn: There's a bit of disconnect in communications though. When the new login was released, Donnovan sent a patch for libsl and discussed the issue indepth with John Hulriman and company.
Saijanai Kuhn: I had to hear it from John
Tao Takashi: I mean if I don't connect or you don't want me to connect (or I don't pay) I might do my own (far better of course) grid
Zero Linden: Tao - you might
Zero Linden: But then again, there is nothing stopping you from doing such right now, either
Tao Takashi: I mean doing decentralization is certainly very important and every technology will go there on the long run (like social networks discover just now)
Zha Ewry: Tao -- Note that Linden can't (and hasn't) stoped people from putting up open grids on openSim
Tao Takashi: I know
Zha Ewry: What this leads too.. tho, is defining how those can interoperate with the Linden Grid (and implictly, each other, if the AGW is clever)
Zero Linden: I think our (meaning both LL and the AWG) has to be to make the value proposition of being part of a single world wide grid more compelling than 100s of non-interoperable grids
Tao Takashi: I am just wondering if this is clear throughout the company that it might also be some thing for the general internet benefit instead of LL
Rex Cronon: except the fact open sim isn't 100% done
Zha Ewry nods at Rex, "Tho, is SL?"
Tao Takashi: nothing is 100% finished ;-)
Morgaine Dinova: I like the strategy of "Release the tiger and hold on tight to its tail" that Lindens seem to endorse. It's pragmatic.
Zero Linden: Well, by the nature of LL's organization, we don't have a single uniform viewpoint from the top down
Squirrel Wood: SL as I see it is an ever evolving place.
Rex Cronon: i don't think u can run scripts on opensim
Tao Takashi: ok, I just want to be sure that not some mornign somebody (important) might wake up and think "ooooh, we have to stop this!!!"
Zero Linden: But I think everyone agrees that an open grid is the direction we must go -
Tao Takashi: but I guess that's not very probable then
Zero Linden: No, it won't
Saijanai Kuhn: Zero, one of our never-ending topics at our weekly meetings is: What should we be doing for Linden Lab and what do we need from them?
Wyn Galbraith: Life and computers have always been evolving. We have come a long way in my lifetime alone. SL and grids like it are a wave of the future, it was destin to happen.
Zero Linden: In my role as "Engineering Director" now, I've spent a large part of the last three months
Saijanai Kuhn: so... what do you need from us?
Zero Linden: meeting with the executive staff weekly, and various groups within the company to help form understand
Tao Takashi: btw, login code is here:
Tao Takashi: unfortunately Pylons/Paste cannot read XML in POST if it isn't form-encoded
Zero Linden: understanding of where these options go, and how as a company we should proceed
Tao Takashi: so that's why there is a data=... in there
Arawn Spitteler wonders if Main Grid Locations might be allocated to Open Sims
Zero Linden: Opening the grid is clearly part of the company strategy
Zero Linden: So - now, moving on
Morgaine Dinova: Cool
Zero Linden: To caps
Tao Takashi: definitely good to know
Zero Linden: Tao related two questions about caps
Tao Takashi: too bad my friend is not online right now, he could ask you himself
Tao Takashi: maybe next time
Arawn Spitteler doesn't know what Caps are: would a cap recap be cursed as recursive?
Zero Linden: a) I have to authorize anyway.... , and b) why not just use the header
Tao Takashi: but I will give him the transcript
Zero Linden: So - let's look at a specific example
Zero Linden: say, "image upload"
Zero Linden: In a traditional website, your browser would have a cookie that referred to your session on the server
Tao Takashi: in AWS you have some header with some access key
Zero Linden: So when you hit
Zero Linden: you pass the coookie in as a header
Zero Linden: which is essentially the same as the access key in a header
Tao Takashi: yep
Zero Linden: Now - that key, or that cookie simply points to some session data
Zero Linden: SO
Tao Takashi: so does the seed cap
Zero Linden: the upload.php script must a) fetch the session data, b) extract your account info, c) decide if you are or are not allowed to upload
Zero Linden: and then, possibly upload the data
Zero Linden: On the other hand, when we use caps
Zero Linden: you use the seed cap to get the upload cap --- and indeed, the seed cap, has to do a, b & c
Zero Linden: then it issues a capabiity for the upload
Zero Linden: so that the upload script it self, when it finally gets invoked via the cap, only need pick up the parameters from the URL - and do the upload
Zero Linden: so - yes, there is no less work being done
Zero Linden: in fact a little more work, since there is an extra HTTP round trip
Zero Linden: BUT
Zero Linden: In our code base, I estimate there are about 300 or so functions
Zero Linden: and really only two or three authorization sequences
Zero Linden: so the code that does the seed cap: seed.php (example) --- has the code for these authorization steps
Zero Linden: and the 300 or so functional pieces of code, needn't have any
Tao Takashi: well, most web frameworks have support for authentication in a separate module which is used
Zero Linden: in our case, those 300 functions are
Tao Takashi: so code is also centralized and I wouldn't have to worry about some seed component to eventually contact other components to ask them if it's granted or not
Zero Linden: spread out over three different web frameworks (C++, Python/eventlet, Apache/PHP)
Zero Linden: and often over dozens of machines
Zero Linden: So sharing code is difficult
Tao Takashi: ok, so the main reason is that technology mix then
Tao Takashi: where it makes sense then.. but my problem is also that capabilities add something new to many developers and every additional concept make sit hard to start coding on something.
Saijanai Kuhn: Zero, Which LInden referred to the caps strategy as a kind of tree of functionality.
Zha Ewry: Zero, don't you also start seeing performance benefits, when you hit the same cap mutiple times in a sessoin?
Tao Takashi: we learned that lesson with Zope
Zero Linden: well, there are a few other advantages: One flexibility - you can continue to do the auth step in the functional modules
Zero Linden: by returning pretty mechanical caps
Zero Linden: And yes, there is no need to re-auth for many things
Tao Takashi: so how does the seed cap decide in your setup which caps are granted?
Tao Takashi: well, it depends on how many caps you need to retrieve.. because it's an additional http request
Saijanai Kuhn: seed-cap gives caps A B and C *always*
Zero Linden: Well, in the current system - there are only a few variables: god level, estate limits
Zero Linden: But the key is that the internal URLs it grants to very generic services, are limited by the internal URL arugments
Zero Linden: for example, we have a very generic upload script that does the work of asset upload
Tao Takashi: well, I'd think if I need to get a cap for every inventory item I want to get details about it might get a bit too much overhead
Saijanai Kuhn: thereare only 4 inventory types
Squirrel Wood: speaking of asset uploads, when will we be able to upload text files into notecards? ^^
Zero Linden: but you can only upload things you create because the seed cap grants internal URLs like
Tao Takashi: even more important, when will we be able to automatically upload images? ;-)
Zero Linden: Uhm, surely you can modify your client right now to do both?
Saijanai Kuhn: Squirrel. Create a libsl bot, email the bot your data and have the bot send the card to the object
Tao Takashi wants some REST API for that ;-)
Tao Takashi: Bot sound like hacks
j3rry Paine: here i am, just a hack
Tao Takashi: anyway..
Zero Linden: So, you want a script to authenticate as you, then request and get the cap to upload images or notecards
Tao Takashi: so another question is then though if not the internal component could actually ask the seed cap with that authorization header. then it would be transparent to the protocol what you use
Zero Linden: This should 100% be possible when we get this whole API going
Tao Takashi: maybe not so clean if it comes to reauthentication though.
Zero Linden: Tao - I'm not sure what you meant there
Saijanai Kuhn: Zero, on that topic, could we see about having a hierarchical structure for the caps?
Zero Linden: Oh - as in caps the support paths underneth them?
Tao Takashi: well, instead of the client asking some other component for access, the internal component could ask the seed cap (and get those parameters back as well)
Gibson Willis: Zero - how does the seed cap auth mechanism you're referring to dovetail with the new HTML web form and redirect based auth?
Tao Takashi: anyway, I guess you don't want to rewrite your modules ;-)
Gibson Willis: not really clear how or if they are related?
Zero Linden: So, usually, the seed cap handler is stateless --- becuase the seed cap matches to something like:
Tao Takashi: but then there is still the question if it's more more fine level auth control, how the seed cap knows what to grant
Tao Takashi: (in the future)
Saijanai Kuhn: Tao, hopefully, the seed-cap is totally statelless
Tao Takashi: well, somewhere you need to have session data stored
Saijanai Kuhn: login, obtain seed-cap, move to next stage
Zero Linden: so the seed code knows who is asking
Zero Linden: just from the URL
Tao Takashi: let me rez my diagram again
Tao Takashi: (and wait for the next auto-return ;-) )
Zero Linden: (by the way, we call "/capabilities/new" - "/caps/grant"
Saijanai Kuhn: just keep it selected
Tao Takashi: so it's step 6 onwards here
Tao Takashi: ok, didn't know if your caps server is somewhere documented
Tao Takashi: but that's implementation specific anyway I guess
Zha Ewry: grant, as in "give access to?"
Zero Linden: no - I'm trying to get a resource to open-source it
Saijanai Kuhn: Zero, assuming we've got a single cap back from login, I'd like to see a clear branching hierarchy defined
Gibson Willis: Zero - could you please provide some context how or if this relates to the new auth rolled out with the .6 client release?
Zero Linden: yes, you are giving access to some internal resource via an external, opaque URL
Saijanai Kuhn: if a client wants a specific *class* of capability, it requests the next level cap for that capability
Zero Linden: Alas, the new auth should make more use of caps than it does at present
Gibson Willis: this seems like an orthogonal (and more sane) approach
Saijanai Kuhn: as much as possible, there should be no overlaps of classes
Tao Takashi: ok, so in step 7/8 the agent host somehow needs to figure out which caps to grant
Tao Takashi: maybe this makes more sense to dicuss once we have another component in place
Zha Ewry: It would be nice, if, as much as possible, we can do this, so that you can ask, for the set of caps you can get ateach state
Zero Linden: yes, I think as soon as we can get enough of an agent domain framework running on a grid, we'll switch to this
Saijanai Kuhn: That way a client (and the server) can idenitfy what kind of client iit is by what branch of the tree of caps it requests
Tao Takashi: is there actually a documentation on how the login works today to a certain point?
Zero Linden: Ah - you mean just order the cap names into a tree, rather than as a single namespace of about 500 caps
Saijanai Kuhn: so a chat-only client doesn't need to know about pposition in-wolrd or even which sim its allegedly standing in
Tao Takashi: I tried to login and the xml-rpc worked and I had a seed-caps but couldn't get any further caps
Gibson Willis: so, the new auth mechanism is a stop-gap until more of the framework is laid out?
Saijanai Kuhn: Zero, right.
Zero Linden: I wonder if we can work out the tree
Tao Takashi: like if I would be able to upload some image just with that basic login sequence and a cap that would help me quite a bit :)
Saijanai Kuhn: a tree of functionality
Zero Linden: or if we should just let clients request the caps they want
Saijanai Kuhn: as much as possible, a tree
Zha Ewry: Making it a tree, or some structure, would make it somewhat easier to do discovery
Zero Linden: I don't think it is a big loss if once during login you have to pass a list of 100 to 300 identifiers for the caps you want
Gibson Willis likes latter idea of caps request
Zha Ewry: Tho.. that's not a deep imperative
Saijanai Kuhn: both for diagramming simplicity and for other stuff
Tao Takashi: make it also in namespaces?
Tao Takashi: so people might define their own caps?
Zero Linden: that allows different impelementations to group them as they see fit
Saijanai Kuhn: the only problem with that is the avatar limit issue
Tao Takashi: ll.agent.imageupload ?
Zero Linden: one implemetnation might see all of chat as a single module, another might see it as two
Saijanai Kuhn: perhaps, a tree and a flat namespace as laternatives...
Tao Takashi: well, the namespace thing would form a tree
Zero Linden: Tao - indeed we need a way to allow extensive extensibilty here
Zero Linden: perhaps (don't throw stones) we should make cap names be URIs
Saijanai Kuhn: the reason why I want it specifically is to allow limited resource clients to auto-define t how much server resources they are using
Zero Linden: like XML does for namespaces
Tao Takashi: maybe
Squirrel Wood: tree.branch.subbranch.leaf <= so if I wand just leaf I request that. If I want more, I request the next higher cap...
Tao Takashi: not sure if it's really about higher caps here
Saijanai Kuhn: that way, sim owners could allow limited resource clients in greater numbers
Tao Takashi: it's more grouping them
Tao Takashi: in ll.agent.imageupload ll.agent wouldn't be a cap
Zero Linden: or perhaps we have all the caps be "flat", but then allow there to be "profiles" which are sets of caps that canbe requested easily at once
Zha Ewry: profiles aren'tbad.. tho.. inevitably
Squirrel Wood: that may work out best eventually
Zha Ewry: someone wants a set that isn't in a profile
Saijanai Kuhn: without trying to decide on a per client basis just what resources are counnted
Zero Linden: well - what if we allow the profile to be allowed to be defined by URL
Zero Linden: so I can ask for a specific set of caps
Zero Linden: or "the set listed at this URL"
Zha Ewry: Ah
Zha Ewry: Interesting
Zero Linden: because that set becomes cacheable at the domain
Zha Ewry: Semi-un-restful
Tao Takashi: so if I would make a custom cap, how would that work with profiles?
Zha Ewry: Because you're depending on the other URL to be there, but.. cute
Saijanai Kuhn: that might work, bu it would make more work for the sim owner
Zero Linden: though I wonder if we are over optimizing --- again, an IM only client that needs 100 caps, is only going to passing about 4k of data
Zero Linden: to request it
Tao Takashi: ah, you are talking about requesting it, not naming it
Zero Linden: yes, you'd request them by cap name
Zero Linden: and then you get back a URL for each one
Saijanai Kuhn: oh, good point. A grid could define client types at the grid level and a sim owner could define his own client types and screen against those if possible
Zero Linden: so another 4k back in response
Morgaine Dinova: If all abilities are decoupled, and the capabilities that enable them are organized in a dependecy tree, then there is total flexibility for any client to pick and choose only what they need, and nothing else.
Tao Takashi: I was more thinking about naming issues if I want to create my special Tao Takashi cap to retrieve my greeting card
Zero Linden: Which, I think you need to be able to do
Zero Linden: so either somethign like
Tao Takashi: which might be
Tao Takashi: and might be in some taotakashi-special-set which you can retrieve to get all my cool caps at once
Zero Linden: and x.private.tao.takashi.thingy
Zero Linden: OR we go the URI route
Tao Takashi: does it matter actually?
Zero Linden: which is more verbose, but all issues of namespace management are "done"
Tao Takashi: Is there a reason those XML namespaces are URIs?
Zha Ewry: Right.. And we don't try to solve the sematnic web issues
Zero Linden: becuase the XML standard defines them to be URIs
Tao Takashi: ok
Zero Linden: not, mind you URLs
Zha Ewry: Just accept the name space
Zero Linden: URIs
Tao Takashi: ok, so just by definition..
Tao Takashi: I always wondered in the beginning what I might find at that URI
Saijanai Kuhn: Zero, by URI, you mean the URL:port/cap/UUID ?
j3rry Paine: "...a URL is a type of URI that identifies a resource via a representation of its primary access mechanism (e.g., its network "location"), rather than by some other attributes it may have. Thus as we noted, "http:" is a URI scheme. An http URI is a URL. The phrase "URL scheme" is now used infrequently, usually to refer to some subclass of URI scheme
Tao Takashi: Sai: No, we just mean naming the caps themselves
Zero Linden: so the difference, for those that may not have that subtly down... is that URI is soley a unique identifier ---- it does not imply that there is a way to get a resource
Zero Linden: a URL is a URI that is a location, and hence tells you how to get a resource at that location
Zha Ewry: You can't, inherently use an URI to *do* anything
Zha Ewry: a URL. you can
Tao Takashi: yes, but if you see something like that it might be a URI or a URL ;-)
Tao Takashi: if you don't know the definition
Tao Takashi: most people don't
Zero Linden: well, if it beginds
it's a URL
Zero Linden: if it begins urn:// it is not
Tao Takashi: anyway, we might choose something as long as you can group stuff
Tao Takashi: so regarding my login is there something missing?
Zero Linden: for the purposes of naming, like XML namespaces, the URI is a sufficient requirement
Saijanai Kuhn: OK, undigressing. We have a bunch of different needs for how caps might be grouped
Zero Linden: well, in our implementation
Zero Linden: it is the agent host that grants the seed cap, not login
Tao Takashi: we need to group them by name so you can define your own and by usage so you can easier access them
Zero Linden: login sets up the agent host, tells it "here comes agent X"
Morgaine Dinova: Should never group any caps except by dependency, otherwise you're hardwiring policy. It's OK to group as a simple shortcut though, as long as the caps are still available separately.
Tao Takashi: the question here maybe is also, what is in the protocol and what is in the implementation
Tao Takashi: as in what is the scope of the protocol
Zero Linden: in response, the agent host does the grant, and then returns the seed cap to login, which in return passes it back to the viewer
Saijanai Kuhn: and spepcific common groupies might have their own name to facilitate resource allocation and avatar limits determinitaion
Tao Takashi: waaa
Zero Linden: sorry - just lengthened autoreturn
Tao Takashi: thanks :)
Saijanai Kuhn: 500 NPCs that do nothing but move might use less resources than a single full-blown client
Tao Takashi: ok, my implementation does not have an agent host yet
Zero Linden: So, your diagram is fine
Tao Takashi: the login server just creates the seedcap and returns it
Tao Takashi: ok, great
Zero Linden: but recognize that the implemetnations may differ
Saijanai Kuhn: and a sim owner might have a use for those 500 baby avatars (like battle simulations)
Zero Linden: now - in general, at some point, we need to think of the caps as just part of the lines
Zero Linden: and not spell them out each time---- just like we don't spell out all the HTTP protocol or the TCP packets
Wyn Galbraith: Baby Battles, frightening.
Zero Linden contemplates battle simulations with 500 babies
Tao Takashi: not sure I get what you mean
Squirrel Wood: I pity the one who gets to change all those diapers :p
Saijanai Kuhn quickly thinks of a combat-related acroynm for B.A.B.Y.
Zero Linden: well - when spec'ing protocols
Tao Takashi: but in fact I wasn't quite sure how to best write it down ;-)
Wyn Galbraith: All that slobber.
Zero Linden: we should be able to say "the function returns a cap to X". Then we show the viewer invoking X, we'll just draw a line from the viewer to the (say) region domain server that implements X
Arawn Spitteler remembers one series, where worlds would be cleared by laser eyed six year olds
Zero Linden: we'll draw the line in some form to remind us that this is via cap, but the actual cap server and it's proxying needn't be drawn
Tao Takashi: ah so we remove the proxy part
Saijanai Kuhn: Battle Aware Bot Interlopers
Zero Linden: we can just assume it
Tao Takashi: ok
Tao Takashi: we can specifiy this in some intro part
Wyn Galbraith: Children of the Damned.
Zero Linden: remember - that it is sort of transparent to both viewer and server
Zero Linden: the viewer would operate no differentlyl if it had a direct URL, and the service doesn't really care how it got invoked
Zero Linden: Tao - yes
Tao Takashi: (btw, not fully convinced that we need caps but going that route now ;-) )
Zero Linden: thanks -
Zero Linden: Okay all
Zha Ewry: Ite better be transparent there
Zero Linden: I'm going to call it quits today
Zha Ewry: Thanks Zero
Saijanai Kuhn: Thanks much
Feep Larsson: Thanks, Zero.
Zero Linden: thank you all for coming
Tao Takashi: Thanks Zero
Wyn Galbraith: Thanks for the extra time, Zero.
Rex Cronon: bye zero
Tao Takashi: full implementation here btw:
Zero Linden: Till tuesday
Tao Takashi: I will post some instructions on how to get it to run soon hopefully
Tao Takashi: just need to test it myself how to get it to run on another server ;_)