User:Zero Linden/Office Hours/2007 Nov 08

• [7:41] Morgaine Dinova: Here's Zero!
• [7:41] Zero Linden: Hi all - sorry I'm late
• [7:41] Wyn Galbraith: Morning Zero.
• [7:41] Morgaine Dinova: Hi Zero
• [7:41] Destiny Niles: You could try Ctl -Shift R for wireframe mode
• [7:41] Dirk Talamasca: DETENTION
• [7:41] Dizzy Banjo: lol dirk
• [7:42] Rex Cronon: hi zero
• [7:42] Arawn Spitteler: Late? Talk to Tree; he got here anywyas.
• [7:42] Dirk Talamasca: Hi Hi Zero
• [7:42] Zero Linden: Well - welcome all to my office 50 minutes
• [7:42] Dr Scofield: hi zero
• [7:42] Morgaine Dinova: Hehe
• [7:42] Thomas Shikami: hello Zero
• [7:43] Zero Linden: To make it clear to all - the transcript of these sessions is posted to the public wiki
• [7:43] Tree Kyomoon: zello zero
• [7:43] Zero Linden: Speak freely and speak openly
• [7:43] Neas Bade: hey zero
• [7:43] Prokofy Neva: Zero, could you tell us who is the author of the original articles in the wiki about the open architecture? can they be signed?
• [7:43] Tree Kyomoon: my pin number is bosco
• [7:43] Tree Kyomoon: oops !
• [7:43] Wyn Galbraith: LOL
• [7:43] Zero Linden: Prokofy - the wiki history section contains authorship information
• [7:44] Prokofy Neva: It's not visible for the original pieces, only later contributions from residents.
• [7:44] Zero Linden: If you mean text that you believe was authored outside the wiki and brough in, you'd have to ask the name on the wiki entry that brought it in
• [7:44] Teravus Ousley: Sorry if I bumped anyone while walking in. Slow connection today
• [7:44] Tree Kyomoon: /prokofy at a zero meeting? interesting....
• [7:45] Prokofy Neva: No, Zero, that's not what I'm talking about
• [7:45] Prokofy Neva: I'm taling about the original articles there on the day it opened, and you know that
• [7:45] Zero Linden: The only documents that I know of are the system image slides, which I drew (and I believe are uploaded by me)
• [7:45] Prokofy Neva: Well I will screen shoot it and email it to you so you can adjust the problem with the failure to show authorship
• [7:45] Zero Linden: There were no other "original" text
• [7:45] Zero Linden: that I know of
• [7:45] Prokofy Neva: Yes, the wiki opened and had a full-fledged road-map with essays in each topic already
• [7:45] Prokofy Neva: unsigned
• [7:46] Burhop Piccard: maybe a link?
• [7:46] Tree Kyomoon: Prok are you after the original members of the AWG?
• [7:46] Prokofy Neva: just go to the wiki and see for yourself
• [7:46] Prokofy Neva: no
• [7:46] Zero Linden: Uhm - no, acutally I Tao I believe did most of the original page work, and did it on the wiki
• [7:46] Prokofy Neva: There we go then -- Tao is the author? but it is not signed
• [7:46] Zero Linden: It is a wiki, at this point it is a collaborative effort - and I think the original page creations are attributed to him.
• [7:46] Neas Bade: zero, back a couple of weeks ago a discussion started on container approaches for the data in the REST services, but the meeting ended before it got very far. Would it be possible to go into that further today?
• [7:46] Prokofy Neva: if it were, it would be visible, unless there's some tekkie wiki thing you're supposed to do to make authorship "pop up"
• [7:47] Dzonatas Sol: it normally is not signed on the "article" unless it is a discussion page
• [7:47] Prokofy Neva: Well it's good if the individual isn't buried in the collective, Zero.
• [7:47] Burhop Piccard: Prof - can you post a link to the page in question?
• [7:47] Prokofy Neva: And takes responsibility for setting the entire tone of the discussion and its basic outlines
• [7:47] Prokofy Neva: Burhop it is the entire wiki, just go there
• [7:47] Zero Linden: A few, like the base page were originally authored by Rob Linden
• [7:47] Prokofy Neva: I don't want to lag out now looking for the obvious, it's the wiki page for this open architecture group
• [7:47] Wyn Galbraith: Maybe log into Wiki is needed.
• [7:47] Morgaine Dinova: You're not meant to sign main namespace articles, because it's a jointly arrived community view, not a debating forum.
• [7:48] Prokofy Neva: Well that's exacdtly what I mean Zero, a few base pages were indeed authored by a Linden
• [7:48] Prokofy Neva: anyone can see that
• [7:48] Prokofy Neva: on the day it opened
• [7:48] Prokofy Neva: but they are not signed
• [7:48] Zero Linden: I don't konw, then, what you mean by "signed"?
• [7:48] Prokofy Neva: and if that is the official opinion of the Lab, and everything else is decorations on a Christmas tree, say so
• [7:48] Exty Yue: Hey, Everyone.. Zha's going to be late.. Amex decided Linden is a scam site again, and the payment web site is insanely slow
• [7:48] Prokofy Neva: authored
• [7:48] Prokofy Neva: showing AUTHORSHIPS AND RESPONSIBLITY AND THE OFFICIAL LL POSITION
• [7:48] Prokofy Neva: Collaboration has its limitations as you know.
• [7:49] Ryozu Yamamoto: This is relavant how Prok?
• [7:49] Zero Linden: Well, we are giong to follow a more open, wiki and community approach unless it proves untenable
• [7:49] Tree Kyomoon: yeah, you have to call AMEX. I have switched my sl and other stuff to mastercard..Amex is a pain in me bony arse
• [7:49] Morgaine Dinova: 43 minutes left .... hope we can get to technical issues.
• [7:49] Wyn Galbraith: No need to shout either.
• [7:49] Prokofy Neva: I just explained: if the roadmap is already devised by LL, and the rest of the comment is merely decoration, it's better to know that at the outset, and also understand the Lindens' real thinking on these issues.
• [7:49] Zero Linden: Folks, please, this session isn't a good place to discuss billing issues
• [7:49] Rex Cronon: dow prokofy want the origninal authors to get credit where credit is due?
• [7:49] Prokofy Neva: Responsibility where responsibility is due.
• [7:50] Rex Cronon: does*
• [7:50] Prokofy Neva: Ok you've answered the question, thanks!
• [7:50] Ryozu Yamamoto: So what if it was written by a Linden or not, it's your own preconception that further input will be discarded. Don't drag down development with your conspiricy theories.
• [7:50] Zero Linden: Okay then - moving on
• [7:50] Prokofy Neva: Not a conspiracy -- they own the servers, they have the information: we do not.
• [7:50] Tree Kyomoon: can we go into that REST stuff
• [7:50] Burhop Piccard: Geometry discussion anyone (ducks and covers).
• [7:50] Zero Linden: I see that Liana has pushed the AWG page reorganization
• [7:51] Zero Linden: And I hope that folks have gotten to see that
• [7:51] Zero Linden: The biggest point is that now there is a framework of the Design Documents
• [7:51] Neas Bade: yep, great to see the work on that
• [7:51] Zero Linden: and section for resources that contribute to the effort
• [7:52] Burhop Piccard: I had a few questions or procedure but I think Liana answered them.
• [7:52] Conover's Flight-Helper: 6.2.5.2 (WEAR ME!): Flight-helper is ready and operational.
• [7:52] Dirk's Dance: Bracelet: OWENIMATIONS DUO DANCER v3.4 -- type /99help for instructions
• [7:53] Thomas Shikami: Is it possible to switch agent inventory listing over to capabilities?
• [7:53] Zero Linden: Well, indeed, I think almost all agent information will eventually be agent capabilities
• [7:53] Tree Kyomoon: wow she's done some great work!
• [7:54] Zero Linden: But - let's take that example and run with it
• [7:54] Dr Scofield: agrees
• [7:54] Rex Cronon: what example?
• [7:54] Morgaine Dinova: Agent info
• [7:54] Zero Linden: <voice type="schoolmarm">Please now open your books to page [1] </voice>
• [7:54] Thomas Shikami: my inv.gz file is just 1.2 MB gz encoded
• [7:55] Thomas Shikami: that could be transferred quickly
• [7:55] Zero Linden: So - quick review of those slides
• [7:55] Rex Cronon: lol
• [7:55] Zero Linden: The innards of the blue box are the hypothetical implementation of an Agent Domain
• [7:56] Tree Kyomoon: and a "Domain" is an intentionally general title, or does it literally mean DNS or IP?
• [7:56] Zero Linden: Really, the only visible parts are the external interfaces of the lower left white boxes, the Agent Hosts, and the lower right boxes, the Agent Services
• [7:56] Zero Linden: Tree - general
• [7:57] Zero Linden: But it stems from the same use of "domain" as DNS: a scoped domain of authority to which some portion of the system is delegated
• [7:57] Tree Kyomoon: which is basically a set of webservices?
• [7:58] Burhop Piccard: Darn I've got a meeting in 3min. Any chance of adding a geometry discussion to a future agenda?
• [7:58] Zero Linden: Well, the Agent Services are expected to be a standard set of webservices accessible at a well known DNS name, such as services.agni.lindenlab.com
• [7:58] Zero Linden: or some such
• [7:58] Zero Linden: Burhop - sure - put it on my wiki page
• [7:58] Zero Linden: and we'll incorporate it in
• [7:58] Burhop Piccard: (will do - bye all!)
• [7:58] Thomas Shikami: I see a problem there. Whenever, avoid a server initiating connection to the client
• [7:59] Thomas Shikami: You know the problems with NAT and FTP already?
• [7:59] Zero Linden: Ditto for anyone else - if you have agenda ideas or desires - put them on my wiki page and I'll organize it
• [7:59] Zero Linden: Yes, I'm aware, but one doesn't expect an agent domain to be run behind someone's home DSL connection
• [8:00] Neas Bade: zero, why not. :)
• [8:00] Zero Linden: The agent domain is like a mail host - it, by it's nature, is something that is openly accessible
• [8:00] Rex Cronon: why not?
• [8:00] Catherine Pfeffer: Why not ?????
• [8:00] Dr Scofield: neas, but then you'd reverse proxy that one out
• [8:00] Zero Linden: Neas - you can run a web server behind a home NAT too....
• [8:00] Thomas Shikami: uhm, it's the other way round
• [8:00] Neas Bade: My fios has more bw that many colleges :)
• [8:01] Neas Bade: right, fair enough
• [8:01] Catherine Pfeffer: Correct (I'm doing that - behind nat)
• [8:01] Zero Linden: But the HTTP protocol, as do the bulk of protocols, assume that the server side is contactable
• [8:01] Thomas Shikami: at agent login, there I see at 4., one hosts connects to the viewer
• [8:01] Zero Linden: If you need to put it behind a firewall, then you have to make allowances:
• [8:01] Zero Linden: A web server offers information to clients it cannot predict - same with the Agent Domain
• [8:01] Neas Bade: as long as normal port forwarding works fine, there shouldn't be an issue
• [8:01] Wyn Galbraith: Prokofy would you please not IM me with SPAM.
• [8:02] Prokofy Neva: type /04
• [8:02] Zero Linden: I expect that almost every protocol we design will be based on HTTP, and hence all port forwarding should work
• [8:02] Neas Bade: yep, great
• [8:02] Zero Linden: The other public interface are the Agent Hosts
• [8:02] Thomas Shikami: well, the Agent Host cannot connect to the Viewer, as the Viewer is almost expected to be behind a NAT nowadays
• [8:03] Zero Linden: but these are not behind a common DNS name - they are like the simulators are today: Until something gives you their address, you don't know how to address them
• [8:03] Zero Linden: T.S.: Indeed, so let's follow the example and see how that is done
• [8:04] Zero Linden: The example is: "Get my top level inventory folders"
• [8:04] Saijanai Kuhn: https://wiki.secondlife.com/w/index.php?title=Architecture_Working_Group&diff=39606&oldid=31612
• [8:04] Zero Linden: Here is one way to run it:
• [8:05] Morgaine Dinova: Don't IM me either please, Prok.
• [8:05] Prokofy Neva: type /04
• [8:05] Thomas Shikami: for everyone, there is the Mute function
• [8:05] Morgaine Dinova: So we're all meant to start muting, because one person here is griefing with IMs?
• [8:06] Prokofy Neva: I hardly think a comment in an IM is "griefing" or "spamming," but raising it in the group chat with limited time is obnoxious, stop it.
• [8:06] Zero Linden: 1) Viewer contacts [2] with some payload like { name:...., credential:....., request-function-sets: [ inventory
• [8:07] Zero Linden: This is sort of saying "I want to log in, but I only need access to inventory services"
• [8:07] Zero Linden: I'm going to ignore the login sequence, and assume it works
• [8:08] Thomas Shikami: ahh, it then returns a capability URL and the URL tells also the agent host to connect to for further requests
• [8:08] Zero Linden: 2) The Agent Server allocates an Agent Host to handle the interaction and returns a response: { agent-host: [3] }
• [8:09] Zero Linden: That thing is a cap to the allocated agent host
• [8:09] Zero Linden: Now
• [8:09] Thomas Shikami: ahh, that works!
• [8:09] Exty Yue: Zero, out of curiosity, how stable, is the capability?
• [8:10] Zero Linden: 3) The viewer uses that agent host "seed" capability to ask for more: Posting to [4] it asks { request-function-sets: [ inventory
• [8:10] Zero Linden: and gets back from the Agent Host { caps: { get-root: [5] get-contents: [6] .... } }
• [8:11] Zero Linden: abreviating the caps here
• [8:11] Dr Scofield: on what basis is the agent host allocated? load or is there something else to be considered?
• [8:11] Zero Linden: Well, of course, that is an implemetnation detail - but we were just talking about that internally
• [8:11] Zero Linden: and we are thinking of combing a measure of both CPU load and Network bandwidth
• [8:12] Dr Scofield: so agent host is just a "proxy" or workhorse?
• [8:12] Zero Linden: Not that some agent domain needn't actually have a separate agent host if it wanted
• [8:12] Dr Scofield: ok
• [8:12] Rex Cronon: why u need to get the whole invetory? can't u get only 1 folder?
• [8:12] Thomas Shikami: it's up to each agent domain developers to decide
• [8:12] Zero Linden: for example: those URLs could have all pointed back into the service.agent.ll.com machines
• [8:13] Zero Linden: Rex - I think the details of how you fetch the inventory aren't defined - my caps there were just an example
• [8:13] Exty Yue: The capabiilty seems to be doing two things. One is security ish.. and the other, is load balancing. One thought,in normal web practice would be to just make the endpoint stable and let things like load balancers to the usual web behavior
• [8:13] Rex Cronon: ok
• [8:13] Zero Linden: BUT - I'm pretty sure you can look at the viewer messages that are efined to see how we would start defining such as set of accessor functions
• [8:14] Zero Linden: Exty- true - but there are two things different here
• [8:15] Zero Linden: One, for many feature sets, there is set of live state that we'll want to keep in a process -- and this state is fragile (unlike, say Amazon shopping carts)
• [8:15] Tree Kyomoon: this is all over TCP/REST and not UDP right?
• [8:15] Zero Linden: so we dont' want to do the tradtional shared session state thing
• [8:15] Thomas Shikami: I'd allow, what libsecomndlife already allows. Fetching one folder, optionally recursive and optionally with contents or structure only
• [8:15] Zero Linden: And two, we've not seen good results with load balancers for our kind of traffice patterns
• [8:15] Exty Yue: nods carefully
• [8:15] Zero Linden: T.S.: I'm pretty sure that is about what the message system does too
• [8:16] Neas Bade: Thomas, that's implementation details for later.
• [8:16] Zero Linden: Tree: Yes, the URLs are all http: or https:
• [8:16] Zero Linden: actualy, I err'd there: all the capabilities must be over https:
• [8:16] Exty Yue: I think that needs to be included someplace, in the design rationale.. so people don't ask the same question. It is the obvious first question
• [8:16] Zero Linden: The other important thing caps are doing here is that the login authorization need only be done once and in one place
• [8:16] Tree Kyomoon: and in XML (SOAP? or?)
• [8:16] Dr Scofield: was just wondering about allowing caps over plain http
• [8:17] Zero Linden: This is really really good
• [8:17] Catherine Pfeffer: Zero : yes, inventory can be very private (to take your example again)... hence https
• [8:17] Thomas Shikami: actually, what I was looking for is a quick implementation of capabilities to be used in 1.18 or 1.19 to fetch inventory. Because to prevent percieved inventory loss, because it just didn't load using the message system
• [8:17] Zero Linden: Tree - yes, all payloads, requests and responses, are XML encoded LLSD
• [8:17] Zero Linden: though we could agree to the binary encoding of LLSD as an option (since HTTP enables content negotiation)
• [8:18] Tree Kyomoon: so no SOAP doc?
• [8:18] Zero Linden: I don't see a lot of advantages of SOAP in this context
• [8:18] Tree Kyomoon: I dont either, just asking
• [8:18] Exty Yue: Not soap, a lot lighter weight, and no envelope munging
• [8:18] Catherine Pfeffer: Tree : I guess moving away from LLSD means extra work... reinventing the wheel...
• [8:19] Zero Linden: Well, actually, SOAP doesn't defined a payload format - so one could use LLSD inside of SOAP as the payload
• [8:19] Thomas Shikami: I also think, RESTful isn't suited to this. The capabilities are more RPC alike
• [8:20] Thomas Shikami: though, inventory by itself could be RESTful, just not the operations done on it
• [8:20] Zero Linden: Well, not quite - many capabilities are things that look RESTful: A capability to set or retrieve an avatar's busy/afk state
• [8:20] Zero Linden: for example
• [8:20] Tree Kyomoon: True zero, and going with SOAP might actually make it extensible in ways we arent considering
• [8:20] Goldie Katsu: wonders if she transfers a radio would it be no SOAP radio
• [8:20] Zero Linden: simple GET and PUT -
• [8:20] Zero Linden: agent presence: "My LIst of Friends and their on-line status" should act like a GET
• [8:21] Dzonatas Sol: HTTP is nice because of the higher level model that can be created with it, and that it can be used on current widespread technology. I also like to make sure that optional context methods (besides HTTP) are provided in the design by abstrction or some allocation.
• [8:21] Zero Linden: because we want people to understand that a) it is cacheable, b) it is a representation
• [8:21] Tree Kyomoon: by GET you dont mean get vs POST right?
• [8:21] Thomas Shikami: on-line status isn't cacheable
• [8:21] Zero Linden: No, I do
• [8:21] Tree Kyomoon: eeek so put the args right into the URL?
• [8:22] Neas Bade: the perceived advantages in SOAP in having infinite flexibility get overwhelmed by the complexity it brings
• [8:22] Thomas Shikami: no args, RESTful doesn't habe them
• [8:22] Thomas Shikami: if you think of args, you're doing RPC
• [8:22] Zero Linden: No- there are not arguments to a query like my example above
• [8:23] Zero Linden: And on-line status is certainly cacheable - the only questin is for how long
• [8:23] Tree Kyomoon: so it just id's the request via the current session instead of relying on args
• [8:23] Zero Linden: One of the things I like about RESTful design is that it forces the engineer to
• [8:23] Catherine Pfeffer: ... suffer ? lol
• [8:23] Zero Linden: own up to the fact that the two sides run independently: Just because I got an RPC return value of "yup, he's on-liine", doesn't
• [8:23] Zero Linden: mean that it isn't already stale
• [8:24] Zero Linden: which means, that essentially, it is "cached" on my return stack - in my local variables
• [8:24] Zero Linden: by casting that explicitly as a GET in HTTP, as a cacheable response - where we make it clear that the network is and may be caching it
• [8:24] Zero Linden: then we draw that essential aspect out in the open
• [8:24] Zero Linden: rather than trying to ignore it
• [8:24] Tree Kyomoon: so the client, network and server duke it out as to who is right?
• [8:25] Neas Bade: plus RESTful interfaces make you think about the application more in terms of data than functions, which makes it a lot easier to integrate with other things
• [8:25] Thomas Shikami: online status is actually a set of transactions and the online status can have a current transaction ID, and there can be online/offline notifications flowing in. Those are then applied in order per friend
• [8:25] Exty Yue: Caching, here, is vital for scale
• [8:25] Zero Linden: Wel, Tree - no, the viewer has to be written with the realization that it isn't always going to have the right information
• [8:25] Tree Kyomoon: and that when in doubt, the server is right
• [8:26] Tree Kyomoon: so no query caching :)
• [8:26] Zero Linden: So, where we don't have to apply a transactional semantics, I think we're going to want to have to avoid it
• [8:26] Neas Bade: you just need to set the Expires: header on the http request
• [8:26] Thomas Shikami: online notifications have transactional semantics
• [8:26] Zero Linden: nothing should depend on if your notion of an avatar's on-line status is right or wrong,
• [8:27] Zero Linden: For example, in Skype
• [8:27] Thomas Shikami: so has many other data that exist in SL
• [8:27] Zero Linden: you can place a call to a user your local application things is off-line
• [8:27] Zero Linden: Well - if we can avoid it, we should, I think
• [8:27] Zero Linden: Some things need it: L$ transfer
• [8:27] Zero Linden: Land purchase
• [8:28] Zero Linden: Some don't - say Sun/Moon position
• [8:28] Zero Linden: And some are less clear: Chat and IM
• [8:28] Tree Kyomoon: so that just means when you place that call, it ignores its last information about that particular user and requeries to see if that user is online specifically
• [8:29] Tree Kyomoon: and the same could apply to object position...say a radar like function returns all the positions at regular intervals, but if you go to touch one, you can get an immediate update on that specific one?
• [8:29] Zero Linden: And that determination is done on the system that has access to "truth" - the server, not the viewer
• [8:29] Sheet Spotter: Why am I picturing all of those annoying "dropped calls" commercials the cell phone providers are running in the US? :-)
• [8:29] Dr Scofield: "access to truth" ... nice
• [8:30] Wyn Galbraith: Can you hear me now?
• [8:30] Tree Kyomoon: well, the truth resides with the place that instantiated the information, so technically it lies with the viewer, and the server hopefully gets and stores the information properly to "rebroadcast" it to everyone else
• [8:31] Neas Bade: which nicely gives you built in handling of client bugs by not trusting the client that it really knows the "truth of the world"
• [8:31] Exty Yue: In general, the web, has very clear expire rules, and we should use them
• [8:31] Zero Linden: is not voice enabled at this hour of the morning!
• [8:31] Zero Linden: Exty - we must use them by virtute of being HTTP - I fully expect HTTP/1.1 compliant caches all over this system diagram!
• [8:31] Neas Bade: tree, I disagree with that last statement. The truth is in the server
• [8:32] Neas Bade: the client requests things happen, but until the server actually says "yup" it's just a request
• [8:32] Zero Linden: So, Actually - I think you both bring up something that I think is unique and excellent about this design
• [8:32] Teravus Ousley: takes Wyn's example a bit further, "Am I online now?"
• [8:32] Tree Kyomoon: If I move to point x,y,z in my viewer, and the server doesnt quite get the message that I moved for some reason and keeps shunting me back to my previous point, the other viewers wont know my position...thats wha t I mean
• [8:32] Dr Scofield: like with e-banking: it doesn't matter what your e-banking app thinks you have, it's the bank that counts
• [8:33] Zero Linden: The "agent" doesn't reside in the viewer. It resides in the Agent Domain.
• [8:33] Arawn Spitteler: My lag meter says I'm not much on line.
• [8:33] Prokofy Neva: Are you planning to implement the nodraw idea that Daniel Linden used to advocate?
• [8:33] Goldie Katsu: (for those who were linking for TUesday's minutes earlier they are up: https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2007_Nov_06 )
• [8:33] Zero Linden: So, really, being on-line is a function of the Agent Domain, not your viewer. Hence, truth of being on-line is really truth about the state of your agent in the Agent Domain
• [8:33] Thomas Shikami: what you have been talking about was the avatar. And the avatar resides on the sim
• [8:33] Dr Scofield: and client is just visualizing agent info?
• [8:34] Dr Scofield: s/agent info/agent status/
• [8:34] Exty Yue: The cilent, should be, as much as possible, as web client, so it only presents, and passes requests up. The server, as always
• [8:34] Neas Bade: dr scofield: that's a very good explaination I think
• [8:34] Zero Linden: Sorry - Prokofy - I don't think this discussion is related to that - nor I have given that issue any thought
• [8:34] Exty Yue: holds the public state
• [8:34] Arawn Spitteler: So, my agent could be active, for a period after my client crashed?
• [8:34] Thomas Shikami: also, for wiki articles, they are never signed. Discussions are signed
• [8:34] Zero Linden: I think of the client (the viewer) as sort of authorized remote control tongs and viewing window -- think putting your hands
• [8:35] Zero Linden: into those funny gloves set in a wall that some laboratories have
• [8:35] Teravus Ousley: :D
• [8:35] Zero Linden: Arawn - as in fact it is today
• [8:35] Neas Bade: heh
• [8:35] Wyn Galbraith: Waldos
• [8:35] Zero Linden: It is just more explicit in this system diagram
• [8:36] Dr Scofield: you could even have a proxy that keeps your agent active regardless of the state of your client and re-connect from a text cleint later
• [8:36] Dr Scofield: "always in-world"
• [8:36] Neas Bade: I know at least for OpenSim, it takes time to reap out the agent once you realize the client is toast. Which is why you have a window (however short) right after a crash that you can't get back in
• [8:36] Dr Scofield: or you could build that into the agent domain...
• [8:36] Exty Yue: So, Zero, it's a normal web client, and, it has privleged ability to send state update requests towards one or more agents and avatars?
• [8:37] Neas Bade: dr scofield, yeh, like having SL screen... attach and detach to your agent
• [8:37] Neas Bade: that would be nifty
• [8:37] Dr Scofield: neas, exactly!
• [8:37] Zero Linden: Yes, yes, yes and yes
• [8:37] Dr Scofield: while you are detached it could play "AFK" animations
• [8:37] Zero Linden: thinks we're all getting the same mental picture
• [8:38] Zero Linden: Or elevator music
• [8:38] Dr Scofield: lol
• [8:38] Neas Bade: heh
• [8:38] Zero Linden: And on that note (pun intended)
• [8:38] Zero Linden: Thank you all for coming today
• [8:38] Neas Bade: thanks zero
• [8:38] Zero Linden: I think this was a great session
• [8:38] Tree Kyomoon: thanks zero
• [8:38] Dr Scofield: thx for a very interesting offic ehour!
• [8:38] Dirk Talamasca: Thanks Zero
• [8:38] Dzonatas Sol: thank you =)
• [8:38] Tree Kyomoon: it was very informative!
• [8:38] Exty Yue: Yes, very
• [8:39] Morgaine Dinova: Cheers Zero
• [8:39] Zero Linden: I'm off to a conference this weekend - where I'll probably takl about SL non-stop for three days
• [8:39] Wyn Galbraith: Thank you for the meeting Zero, always an education in more ways than one. :)
• [8:39] Zero Linden: If my voice is gone on Tuesday, you'll know why!
• [8:39] Exty Yue: When we deviate from bog standard web, try and explain why
• [8:39] Catherine Pfeffer: thanks zero.. and thanks for the funny images (the gloves, the elevator music) ;-)
• [8:39] Wyn Galbraith: We don't need your voice, just your typing.
• [8:39] Prokofy Neva: the tongs
• [8:39] Dr Scofield: who needs voice in-world?
• [8:39] Exty Yue: That's going to help other people understand the design in many useful ways
• [8:39] Tree Kyomoon: I'll post the transcript if no one else objects ?
• [8:39] Zero Linden: Those should, I think get into the background info in the eventual document set!
• [8:39] Dr Scofield: it help me understand the design much better
• [8:39] Saijanai Kuhn: ah, Zero. A heads up: https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft
• [8:40] Zero Linden: Well - we did announce up front that it is all going to be posted publically
• [8:40] Zero Linden: So, thank you Tree for doing so every week!