User:Zero Linden/Office Hours/2007 Dec 13
< User:Zero Linden/Office Hours
Jump to navigation
Jump to search
Revision as of 09:01, 24 January 2008 by Zero Linden (talk | contribs) (New page: Transcript of Zero Linden's office hours: {| |- style="vertical-align:top;background-color:#FFFFFF;" | | colspan="2"|''Desu Uriza gave you Al Azem Welcome Back...)
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 yahoo.com 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 | |
| Candy Durant shouts: ANYONE WANNA TAKE A GANDER AT A FREAKY SL CLOTHING ISSUE?? | ||
| 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: | sl.base.cap.foo 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 ;_) | |