User:Zero Linden/Office Hours/2008 Jan 10

From Second Life Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Transcript of Zero Linden's office hours:

[8:36] Harleen Gretzky: He is typically late to his OH
[8:37] Rex Cronon: also, there is only one transcript for the whole month of december:(
[8:37] Leffard Lassard: =
[8:37] Zha Ewry: Ah.
[8:37] Zha Ewry: Zero's on
[8:37] Arawn Spitteler: Ask/Nag when he shows
[8:37] Zha Ewry: And there he is!
[8:37] Harleen Gretzky: Hi Zero :)
[8:38] Arawn Spitteler: All welcomes Zero
[8:38] Rex Cronon: he is close, and i think he can hear
[8:38] AC: Hi Zero !
[8:38] Zha Ewry: Morning Zero
[8:38] Zero Linden: Gooooood morning all
[8:38] Rex Cronon: hello zero
[8:38] Dr Scofield: hi all
[8:38] Rex Cronon: hi
[8:38] Tao Takashi: Good morning, Zero
[8:38] Arawn Spitteler wonders if Vineland is using Havoc 4, and if Zero is the person Zarf would want to ask about strange phenomena.
[8:40] Rex Cronon: zero, is there an ATA for the transcripts, for december, and the one from tuesday?
[8:40] Wyn Galbraith: Morning all.
[8:40] Rex Cronon: hi
[8:40] AC: hello Wyn
[8:40] Zero Linden: Vineland is not using Havoc 4 as far as I (or Zarf) knows
[8:40] Zero Linden: Rex... ETA?
[8:40] Rex Cronon: eta*
[8:41] Rex Cronon: sorry, seems like my fingers are a little slow today
[8:41] Zha Ewry: Zero.. As I cover my white board with grids about trusted/untrusted sim/server relationships, do you want to consdier
[8:41] Arawn Spitteler: Passive but Physical Object went off world, there.
[8:41] Zha Ewry: agent domains seperate from regionas, or assume they come a a pair?
[8:41] Dr Scofield: zha, why would they become a pair?
[8:42] Zha Ewry: For simplicity
[8:42] Zha Ewry: But. I assume they won't.
[8:42] Zha Ewry: Just makes more cases
[8:42] Zha Ewry: Raises questions like "Do we hand off agents from agent DomainX, to agent domainY"
[8:42] Zero Linden: Well, Tree K. was putting up the transcripts for me ---
[8:42] Tao Takashi: what does "hand off" mean?
[8:42] Arawn Spitteler wonders why replacement of one object would stop the Grid: The Grid is supposed to have some parrallel to The Internet, but the Internet was designed to recover ffrom a nuclear war.
[8:42] Zero Linden: I have the raw transcript for Dec., but (alas) without time stamps.... I'll put them up today
[8:43] Zero Linden: Zha - I've always assumed that they don't
[8:43] Zero Linden: come as pairs
[8:43] Tao Takashi: I did put one up I had for Novermber I think
[8:43] Zha Ewry nods
[8:43] Zha Ewry: Okies
[8:43] Zha Ewry: I'll do the full messy case then ;-)
[8:43] Zha Ewry mourns the last four sqaure inches of her whiteboard
[8:43] Tao Takashi: I think we need the full messy case ;-)
[8:43] Zero Linden: I don't like the idea of enforcing that every AV should need an identity-fragment on an Agent Domain associated with a Region Domain that they want to visit
[8:44] Zha Ewry: Nor do I.
[8:44] Zero Linden: smacks too much of to sliding in to the current situation on the internet today
[8:44] Zha Ewry: Just makes the picture a it middier
[8:44] Zha Ewry: *muddier
[8:44] Dr Scofield: eeek
[8:44] Zha Ewry: I'm about 1/3 of the way from having a usefuil layout of the basic problems
[8:44] Zha Ewry: So.. we can talk about what trust relationships we need in all the cases.
[8:44] Wyn Galbraith thinks Tree has been busy days as she is.
[8:44] Tao Takashi: I was trying to mention virtual worlds in the dataportability.org group btw ;-) so they think a bit further then just personal data but also content
[8:45] Zha Ewry: Also raises some interesting questoins about what ahppens if we move scripts to agent domains
[8:45] Zero Linden: I think, long term, that is inevitable
[8:45] Zha Ewry nods
[8:45] Zha Ewry: I agree
[8:45] Zha Ewry: Which.. means we'll dcoument some fun things
[8:45] Zero Linden: It is sort of like the inevitability of scripted IRC/Chat clients.....
[8:45] Tao Takashi: you mean running scripts on agent domains and just getting object updates etc. from the region domain?
[8:45] Zero Linden: at some point you are going to want to automate the way your avatar does some things....
[8:46] Tao Takashi: or are we talking about the client?
[8:46] Zha Ewry: Region sims allowing aves in, are gong to have to also allow the agent domain to see some tihings for the scripts, in a sesnible way
[8:46] Zero Linden: And again, I fear for the complexity, but I think that running attachment scripts in the AD will be a big win for usability
[8:46] Dr Scofield: zero, why not do it via the client?
[8:46] Zha Ewry: I tend to agree zero
[8:46] Dr Scofield: for automation
[8:46] Zha Ewry: And.. Actually, I think the complexity isn't that bad, because you shed a lot of complexity on the sim side
[8:47] Tao Takashi: and won't scripts in AD add a lot more of network traffic?
[8:47] Zero Linden: What advantage to on the client? Then your ability to do things depends you being on the right machine with teh right files?
[8:47] Zha Ewry: You get much smoother handling of the hand offs
[8:47] Zero Linden: or do we serve the scripts to the client?
[8:47] Zero Linden: it does remove the one thing safe from poaching: scripts - since they are never sent to the client now
[8:47] Dr Scofield: you could do that
[8:48] Tao Takashi: I think we need both.. some client specific scripting and some server side. They might serve different purposes
[8:48] Rex Cronon: the code, or the precompiled bytes?
[8:48] Dr Scofield: i was thinking about autmating your avatar
[8:48] Dr Scofield: not shipping the scripts for in-world objects, sorry
[8:48] Zero Linden: Well - I suppose if the RD grants capabilities to the AD for passing events and commands from attachement scripts, then the
[8:49] Zero Linden: AD could pass that capability on to the viewer along with the script and let the viewer run it....
[8:49] Tao Takashi: like clientside scripts might be like Firefox extensions
[8:49] Dr Scofield: didn't mean to confuse
[8:49] Tao Takashi: e.g. add IRC support as an example
[8:49] Tao Takashi: but that's different from scripted attachments
[8:49] Zero Linden: there is the issue of persisting the state of the script... especially when the connection between viewer and AD gets severed (say if the viewer crashes..... whcih I realize is a (cough)common(cough) event)
[8:49] Zha Ewry nods
[8:50] Zha Ewry: I think, in time, we'll have automatoin in both places
[8:50] Zha Ewry: We *can't* stop client side automaion
[8:50] Dr Scofield: yes...my comment related to automation of avatar via cleint
[8:50] Arawn Spitteler doesn't know AD from Client, but thinks straight Java could be used for Client Scripting.
[8:50] Zha Ewry: But.. we'll want AD automatoin
[8:50] Zero Linden: Sigh - probably - and probably in a multitude of languages and lib frameworks....
[8:50] Dr Scofield: not in-world objects/attachments
[8:50] Zero Linden: (AD = Agent Domain)
[8:51] Tao Takashi: I would hope for it not being just Java ;-)
[8:51] Tao Takashi: but anyway
[8:51] Dr Scofield: ;-)
[8:51] Zha Ewry: OK. So I'll try to habe a first draft tabele and summary in the wiki for Tuesday
[8:51] Kurt Stringer: so there would be different scripts for prims and avatars?
[8:51] Zha Ewry: *have even
[8:51] Kurt Stringer: agent vs region?
[8:51] Arawn Spitteler: Scale of Skill, Java for those expanding from Server Side LSL, and better for those who can actually program
[8:51] Zero Linden: Don't know...
[8:52] Rex Cronon: the problem will be than if the owner of the script trusts the creator
[8:52] Tao Takashi: so if scripts are run on he agent domain, what would actually needed to be transferred? I guess scanner commands and such are simply sent to the region and some result comes back then
[8:52] Dr Scofield: zero, could we discuss the secondlife:///app/login issue a bit? as neas pointed out on sldev this is the first cse where we actually run into issue re grid interop
[8:52] Zha Ewry: The sense informaoin is the obvious big one
[8:52] Tao Takashi: I can program but it's not better for me ;-)
[8:52] Tao Takashi: but that's a discussion for later anyway
[8:52] Kri Ayakashi: I believe that it won't be long before we'll see some custom clients with client side scripting... I'm actually suprised there aren't any out there yet
[8:52] Tao Takashi: so what else do attachments actually do?
[8:52] Zha Ewry: And.. this does, I think, imply, that scripts will be in at least two places
[8:53] Tao Takashi: HTTP probably but there it doesn't matter from where it gets triggered
[8:53] Rex Cronon: and java code can be decompiled quite easy, so can the creator trust the user?
[8:53] Zha Ewry: Because, you'll have scripts in rezzed objects, whichh don't belong to agents
[8:53] Zero Linden: hmmmm...... I was just thinking of generalizing the script interface so that one could have a script proxy on the sim for each attachemetn script (since they need to sense and interact with the sim environment)
[8:53] Zha Ewry: So.. one imagines those get to run out of the agent domain
[8:53] Zero Linden: but have all the events and calls proxyed to/from the script running on the Agent Domain (or Viwer)
[8:53] Zero Linden: this should be a generalized facilty
[8:53] Zha Ewry: (On the regions, or sepersate, doesn't much matter)
[8:53] Zha Ewry: and.. Yes.
[8:54] Zha Ewry: Because, if we decouple fully, we get ncier scaling
[8:54] Tao Takashi: would a region then have a general e.g. sense API which I eventually can use completely free (without a script in an attachment)?
[8:54] Zero Linden: it would allow you sell objects that had scripts where you didn't want the script to be out... and were willing to provide the compute power to run it
[8:54] Zero Linden: hmmmmmmm.
[8:54] Zero Linden: I'll talk to Babbage about this
[8:54] Tao Takashi: this would mean sensors without actual objects around
[8:54] Saijanai Kuhn exepcts to be reading a lot to catch up
[8:54] Zha Ewry: Erk.
[8:55] Zha Ewry: Interesting thing. The prims in the attachments are still goign to be on the region for people to see
[8:55] Zha Ewry: HUD ones, no
[8:55] Zha Ewry: HUD ones, are hidden
[8:55] Zha Ewry: But.. the prims rez in the regoin, don't they?
[8:55] Tao Takashi: well, do we need attachments then for these scripts if they don't show anything? ;-)
[8:55] Tao Takashi: like twitterbox
[8:55] Zero Linden: Tao - it might be a reasonable construction to enforce that anything that senses must be a script in an object (allows it to be governed by parcel controls, for example)
[8:55] Tao Takashi: well, it shows something but it wouldn't need to
[8:56] Zha Ewry: HUD attaches get interesting
[8:56] Tao Takashi: I am just thinking loud not necessarily saying that it's a good idea
[8:56] Tao Takashi: it might save prim count though
[8:56] Zero Linden: but it could be that a kind of script is just a generic proxy connection that sends events via HTTP and gets functions to invoke from HTTP
[8:56] Zha Ewry likes the thinking out loud
[8:56] Dr Scofield: HUd attaches would be a good cse for AD
[8:56] Saijanai Kuhn: so the case of attachments that are no permissions, but have scripts, will be handled differently than attachments WITH scripts...
[8:56] Saijanai Kuhn: than attachments WITHOUT* scripts
[8:56] Zha Ewry scribbles on her white board
[8:56] Tao Takashi: so what else do attachments do? maybe rez something out of their inventory
[8:57] Neas Bade: if the scripts were not too latency sensitive, it would be nice to allow the HTTP connections to be fully outside of grid
[8:57] Zha Ewry: Animations
[8:57] Zha Ewry: xmlrpc
[8:57] Zha Ewry: (tho, we hoope that goes away)
[8:57] Zha Ewry: chat
[8:57] Tao Takashi: so why not simply serve attachments from the AD, too?
[8:57] Rex Cronon: push
[8:57] Zero Linden: Neas - absolutely
[8:57] Tao Takashi: or are we saying this already? :)
[8:57] Kri Ayakashi: while on topic of transfer protocols wouldn't it be better to use something like XMPP instead of HTTP for this?
[8:57] Zero Linden: Tao - I think we are saying this
[8:57] Tao Takashi: ok
[8:57] Neas Bade: Kri, why XMPP?
[8:58] Zero Linden: ditto?
[8:58] Kri Ayakashi: for one latency and amount of data sent is smaller
[8:58] Kri Ayakashi: it's a two-way protocol
[8:58] Wyn Galbraith's work has switched to days so she has to go to work now.
[8:58] Neas Bade: kri, you've been using bad http servers then :)
[8:58] Saijanai Kuhn: Later Wyn
[8:58] Wyn Galbraith: B-bye!!! :D
[8:58] Zha Ewry: By Wynn
[8:58] Rex Cronon: bye wyn
[8:58] Dr Scofield: XMPP let's you deal better with async events
[8:59] Neas Bade: getting low http latency and good http scalability is a pretty well understood solved problem
[8:59] Zero Linden: Kri - it is true that XMPP is symetric, which is nice, but I don't think it's overhead is that much less than HTTP
[8:59] Zha Ewry: OH! Before I foget, Zero, you might want to update your "hours" sign on the easel there.
[8:59] Neas Bade: xmpp has some "fun" scaling issues that aren't all that well understood
[8:59] Neas Bade: if you look at the xmpp spec, the overhead really is more
[8:59] Dr Scofield: you only have to establish the connection once
[8:59] Zero Linden: My biggest concern with XMPP is that it doesn't really have the wide tool support
[8:59] Dr Scofield: then it's just XML messages
[8:59] Zha Ewry: you'd have to do HTTP, I think
[8:59] Zha Ewry: Becuase that's what eveything talks
[9:00] Neas Bade: dr scofield, connection overhead shouldn't be that big a deal
[9:00] Zero Linden: Well, the TCP handshake packets are a fart-in-a-whirlwind compared to the headers etc....
[9:00] Zha Ewry and the acres of angle brackets
[9:00] Zero Linden: XMPP doesn't play well with most XML tools (as it sends fragments of XML documents)
[9:00] Neas Bade: you can use keep alive and pipelining if you really think that it is causing issues
[9:00] Zha Ewry worries about the world wide angle bracket supply
[9:00] Dr Scofield: once you go for encrypted connection setup becomes expensive
[9:00] Neas Bade: yeh, HTTP is simple and nice
[9:00] Zero Linden: And there are many frameworks for serving XMPP
[9:01] Zero Linden: The big plus for me is the symetric connection no matter which way established
[9:01] Saijanai Kuhn notes that the avatar domain attachements thing seems to have died. Too many variables, not enough info?
[9:01] Tao Takashi: XMPP gets mentioned more and more it seems
[9:01] Tao Takashi: on the DiSo project they want to use that for contact detail updates
[9:01] Zha Ewry: Neas, am I right in recalling there has been some discussion in OpenSim land, about breaking scripting out into seperate spaces?
[9:01] Zero Linden: however, we've been doing some reasonable things with HTTP using the long poll technique
[9:01] Neas Bade: Tao, but typically not by folks that actually have had to implement an XMPP server :)
[9:02] Kri Ayakashi: you mean comet?
[9:02] Saijanai Kuhn: Zero if you mean EventQueueGet, that's only "reasonable" if you're sure what is going on
[9:02] Tao Takashi: Neas: They are actually implementing something for Wordpress right now
[9:02] Tao Takashi: but I don't know the details
[9:02] Zero Linden: sorry to open a fresh wound....
[9:02] Dr Scofield: neas, there are some decent XMPP servers around
[9:03] Neas Bade: we did that discussion in OpenSim land regarding region comms a few months ago, and a bunch of folks from Intel with significant XMPP experience said "you really don't want to go there. Beyond a certain scaling factor things fall over, and no one has really sovled them yet"
[9:03] Tao Takashi: well, comet also seems to grow slowly
[9:03] Neas Bade: there is a reason that HTTP is used everywhere at this point, it is really well proven for all kinds of tasks
[9:03] Dr Scofield: google seems to have
[9:03] Tao Takashi: Neas: is this readable under some URL? :)
[9:03] Neas Bade: check out the opensim-dev mailing list archives
[9:04] Tao Takashi: thanks, will do
[9:04] Neas Bade: http://opensimulator.org - follow links
[9:04] Neas Bade: it would have been Octoberish IIRC
[9:04] Dr Scofield: neas, that's just taking the "i've got a big hammer...and, oh, look, lots of nails here" approach
[9:04] Neas Bade: Dr Scofield, perhaps, but you can't underestimate the power of using technologies people already know
[9:05] Zha Ewry shrugs
[9:05] Zha Ewry: "Big swiss army knife,"
[9:05] Neas Bade: you want to bring in developers to interlock with these bits
[9:05] Neas Bade: and there are at least 100x more people that know HTTP than XMPP
[9:05] Saijanai Kuhn: properly designed, this stuff should be changeable down the road, if need be...
[9:06] Saijanai Kuhn: without HUGE hassles, even
[9:06] Kri Ayakashi: that's true but I dont think it's a good argument why to use something or why not to use something
[9:06] Zero Linden: Well, I'm equally concerned about things like - HTTP's failure modes are well understood - what happens when an XMPP connection drops?
[9:06] Neas Bade: yep
[9:06] Dr Scofield: true, i'm just concerned that we use HTTP for purposes it was never intended for
[9:06] Zero Linden: Caching is possible in HTTP, but not XMPP
[9:06] Tao Takashi: Well, I think I'd like HTTP more for that everybody knows it
[9:06] Neas Bade: HTTP was intended for reading physics papers
[9:07] Dr Scofield: pull
[9:07] Neas Bade: so we all use HTTP for things it was never intended for :)
[9:07] Tao Takashi: when I heard about XMPP I tried to read up upon it but stopped soon again as it seems a bit too read
[9:07] Dr Scofield: but not push
[9:07] Zha Ewry shrugs "90% of the HTTP uses theseb days are well beyond Mosaic"
[9:07] Tao Takashi: well, it depends on how many people will do these things with it and servers/clients will simply evolve
[9:07] Dr Scofield: ok, i'll shut up XMPP wise
[9:08] Zha Ewry: Zero.. how many singletones are there in SL at this point, which won't surivive wihout pluatlity in an open Gridded environment?
[9:08] Zero Linden: So - this has been tackled several times in HTTP: ModPubSub comes to mind and Rohit Khare's thesis ARREST - which is his pub/sub extention to REST
[9:08] Zero Linden: Hmmm... F-Sharp above middle C?
[9:08] Neas Bade adds to his reading list
[9:09] Tao Takashi: sooo, if the attachments are on the AD, how would they be rendered on the client?
[9:09] Dr Scofield: secondlife:///app/login?
[9:09] Tao Takashi: the client directly gets them from the AD? or via the RD?
[9:09] Neas Bade: yeh, the uri discussion is something I obviously have great interest in :)
[9:10] Zero Linden: Tao - good question... don't know
[9:10] Zero Linden: Dr - what are you asking?
[9:10] Neas Bade: Zero, have you kept up on the sldev thread regarding secondlife:// uris?
[9:10] Zero Linden: Zha - wouldn't it be easier to ask it the other way round?
[9:10] Tao Takashi: of we assume bad RDs then AD => client would probably be better
[9:10] Dr Scofield: the loginpage/web auth currently does not really return any information about the grid to connect to
[9:10] Zero Linden: Neas - no
[9:10] Neas Bade: it started from a discussion with Tess yesterday that Dr Scofield summarized
[9:10] Tao Takashi: the client will get these things anyway
[9:10] Zha Ewry: LOL
[9:11] Zha Ewry: Possibly
[9:11] Tao Takashi: and what about bad ADs? :)
[9:11] Zero Linden: "Yo - I'm one baaad AD, ya hear?!"
[9:11] Saijanai Kuhn: AD...?
[9:11] Zero Linden: Agent Domain
[9:11] Tao Takashi: I am not sure running scripts on ADs will solve the problem ;-)
[9:11] Tao Takashi: if it's not the AD the script creator choose to trust
[9:11] Dr Scofield: you can tell the latest clients to go your own loginpage, but all you can do in that is return the secondlife:/// URI
[9:12] Dr Scofield: we discussed with tess how we could add the grid information
[9:12] Tao Takashi: I wonder why the grid information cannot be simply in some config file on the FS
[9:12] Neas Bade: right, the issue is that secondlife:/// uri like things have implicit hostname
[9:12] Dr Scofield: (a) use a parameter like grid=.....
[9:12] Saijanai Kuhn: Was that after the Groupies meeting, or another talk?
[9:12] Tao Takashi: but then again I think I am not too much into the details of that problem
[9:13] Neas Bade: and we really need that to be an explicit hostname to make it work well with multiple grids
[9:13] Saijanai Kuhn: and did it get posted to the wiki?
[9:13] Dr Scofield: (b) use a proper URI: secondlife://grid.com/app/login?...
[9:13] Harleen Gretzky thought Tess was looking into adding -loginuri
[9:13] Dr Scofield: saijanai: i posted the chat log to the wiki
[9:13] Saijanai Kuhn: great
[9:13] Zero Linden: ah- is the concern over the integration of the correct URI syntax (secondlife:///) with the previous, tehcnically non-compliant (second://RegionFoo)
[9:13] Dr Scofield: and the summary to sldev
[9:13] Zero Linden: ?
[9:13] Dr Scofield: yes!
[9:13] Neas Bade: right, and more importantly getting to a point where
[9:13] Dr Scofield: secondlife:/// it turns out addresses the client
[9:14] Neas Bade: secondlife://osgrid.org/region/Wright%20Plaza/10/10/20 is a legitimate URI
[9:14] Saijanai Kuhn: https://wiki.secondlife.com/wiki/AWGroupies-2008-01-08
[9:14] Zero Linden: okay - so, since I'm the RFC-weenie inside LL that insisted on that third slash
[9:14] Zero Linden: let me explain
[9:14] Dr Scofield: whereas secondlife://region/X/Y/Z addresses a location in the grid
[9:14] Dr Scofield: and neas example makes a lot of sense
[9:14] Zero Linden: So - we've GOT an exsiting, ill-formed, non-compliant scheme
[9:14] Neas Bade: because SLURLs should really identify a unique network resource
[9:15] Zero Linden: secondlife://Grasmere/123/345
[9:15] Zero Linden: is Legal
[9:15] Zero Linden: really
[9:15] Dr Scofield: agree on that one, zero :-)
[9:15] Zero Linden: because the URI syntax requires that if your scheme starts with two slashes
[9:16] Neas Bade: yep, it's not that it isn't legal
[9:16] Zero Linden: THEN, the first segment MUST have the syntax for domain names
[9:16] Neas Bade: it's that by not including explicit hostname, there is an implied grid name
[9:16] Neas Bade: and to make all things equal, we should be explicit about the gridname
[9:16] Zero Linden: Well, the old syntax is what it is.... I can't fix that
[9:17] Neas Bade: right, but we could adjust over time
[9:17] Neas Bade: my last post to sldev gave a set of steps that could get you there
[9:17] Zero Linden: but let's make one thing clear, even if you put a host name there - nothing in the URI spec says that that has to be the host name you contact
[9:17] Chosen Raymaker: or introduce a new scheme name
[9:17] Zha Ewry: There is a fair question, about whether we can fix it now, so we don't have to revisit it in six to twelev months
[9:17] Neas Bade: correct
[9:17] Zero Linden: so -
[9:17] Saijanai Kuhn: or rather, so we might not have to revisit it...
[9:18] Zero Linden: secondlife: scheme is NOT intended to be the URLs of locations in world
[9:18] Zero Linden: really- that would be a poor choice
[9:18] Neas Bade: but, by making secondlife:// URIs act more like http:// URIs, it makes life a lot easier
[9:18] Saijanai Kuhn: the best laid plans of avatars...
[9:18] Zero Linden: I say, just use an HTTP name
[9:18] Zero Linden: http://slurl.com/secondlife/Grasmere/178/113/27
[9:18] Zero Linden: that is the URL of this location
[9:19] Neas Bade: ok, so where can I type that into the location browser in my SL client?
[9:20] Zero Linden: secondlife: is a scheme for invoking one's client to do something
[9:20] Neas Bade: I understand that is the way it is today
[9:20] Zero Linden: Neas - you can't 'cause our viewer has no address bar!
[9:20] Neas Bade: but it seems like it wouldn't be much to work to make secondlife:// uris actually be network resources in a sensible way
[9:21] Saijanai Kuhn: well, the map *could* be, but you'd need to have it parse and resolve slurls
[9:21] Zero Linden: It seems like an indirection that is generally uneeded
[9:21] Zero Linden: for example
[9:21] Neas Bade: and I really think that until that is make explicitly so, there is going to continue to be assumptions made in the client that don't work for alternate grids
[9:21] Zero Linden: let's take secondlife:///app/profile/Zero/Linden
[9:21] Neas Bade: it's social engineering as much as anything else
[9:22] Zero Linden: should that be *the* name of the resource that is my profile?
[9:22] Zero Linden: seems far less useful than
[9:22] Neas Bade: but your profile is only valid in the context of a specific grid
[9:22] Zero Linden: http://grid.secondlife.com/agents/Zero/Linden/profile
[9:23] Zero Linden: Ah - I see what you are driving out
[9:23] Neas Bade: ok, then get rid of secondilfe:// entirely, and just use http
[9:23] Zero Linden: driving at
[9:23] Saijanai Kuhn: actually with universal avatars...
[9:23] Zha Ewry listens closely
[9:23] Zero Linden: right - only the only way to get interaction between a web browser and a more complex UI (say, a viewer app) is this goofy scheme HACK
[9:23] Neas Bade: right
[9:23] Harleen Gretzky: Your profile is actually: secondlife:///app/agent/2e3e325b-2887-4a3c-aceb-c94227019b22/about already
[9:24] Neas Bade: and my point has been that instead of just doing the minimum for the hack using secondlife://, make the secondlife URIs explicitly contain grid infomation in them
[9:24] Neas Bade: which then makes the ideas of navigation between grids, and refernce points of the secondlife urls very explicity
[9:25] Saijanai Kuhn: /grid-"Second Life"
[9:25] Saijanai Kuhn: =*
[9:25] Zha Ewry: And.. sets us up nicely for the future
[9:25] Neas Bade: and starts to form a model where the secondlife scheme looks a lot more like www
[9:25] Neas Bade: zha: exactly
[9:25] Neas Bade: stop thinking of secondilfe:// as a hack to trick the client to do something, and think of those URIs as actual network resources that the client is asked to load
[9:26] Zero Linden: Neas - that then brings up the issue of "what identifies a grid"?
[9:26] Zero Linden: which domani name?
[9:26] Zero Linden: do we need to make the Agent Domain / Region Domain distinction now?
[9:26] Saijanai Kuhn would like to see a UUID for each grid but
[9:26] Neas Bade: hostname:port of the login server would be a reasonable starting place
[9:26] Neas Bade: as that is going to be the entry point
[9:26] Zha Ewry: As its an overlay construct over the www name space
[9:27] Zero Linden: hmmm... but then, here's the problem with that
[9:27] Zero Linden: if you use the login server and port
[9:27] Zha Ewry would hate to see it nind all thwe way to a single domain name
[9:27] Tao Takashi: btw, those profiles should contain microformats :)
[9:27] Zero Linden: BUT, that isn't the actual place the viwer goes to get the info it needs
[9:27] Zero Linden: THEN there is some form of transformation that the viewer needs to do to get to the right place
[9:27] Neas Bade: right, but google.com is 100k machines
[9:27] Tao Takashi: but then again there is not too much to markup with microformats anyway
[9:28] Neas Bade: but you can have a single name that gets you to 100k machines, and the http spreader figures out where you really go
[9:28] Zero Linden: well, that isn't quite the same, Neas
[9:28] Kri Ayakashi: btw, will SL follow login ideas like OpenID? meaning having an account on one grid lets you in to other grids ?
[9:28] Chosen Raymaker: Zero: An unrelated question before you close? Can you tell us why groups are limited at 25? If it is to limit server load, what traffic exactly is significant in this connection?
[9:28] Zha Ewry: In the one case, it's a http endpoint, in this case, we're nming an ovrlay
[9:28] Zero Linden: when you go to google.com - routers , level 2 swithces, and load balancers pick one of those 100k machines
[9:29] Zero Linden: but they are all equiavelent
[9:29] Zero Linden: for whatever you ask of google.com
[9:29] Nika Talaj: ? is a grid a service or a server
[9:29] Neas Bade: mail.google.com is pretty stateful
[9:29] Neas Bade: and that is a lot of machines
[9:29] Zero Linden: right - and they have load balancers that deal with that
[9:29] Zero Linden: BUT this is different
[9:29] Zero Linden: well
[9:29] Zero Linden: may be not
[9:29] Neas Bade: right, but those aren't l2 balancers
[9:30] Zero Linden: but what I'm saying is that if you see a resource identified by //google.com/ - you ask your question by connecting to google.com
[9:30] Neas Bade: to get mail.google.com working right, you are balancing much higher up, giving all the stateful ajax
[9:30] Neas Bade: docs.google.com is even more so the case, where your live editting is updated every 10 seconds
[9:30] Zero Linden: if you see something like secondlife://login.agni.lindenlab.com:443/app/profile/2e3e325b-2887-4a3c-aceb-c94227019b22/about
[9:30] Zha Ewry: def not l2 balances, no
[9:31] Neas Bade: anyway, the point is that having a name for a grid being a hostname shouldn't be a big deal
[9:31] Zero Linden: you need to connect to login.agni.lindenlab.com:443 to get the asnwer
[9:31] Zero Linden: and - it turns out, that that machine can't answer that question
[9:31] Neas Bade: then that URI shouldn't be returned
[9:31] Neas Bade: or if it is, we have 30x codes to bounce to the right location
[9:31] Zero Linden: Right now, the secondlife:/// scheme is intended to control the viewer, by asking it to do things with respect to the grid it is connected to now
[9:31] Kri Ayakashi: well it could use some rewrite rules based on the URL provided to bounce the request to other machine
[9:31] Zero Linden: The only excpetion is secondlife:///app/login
[9:31] Neas Bade: right, I do undestand what is is today
[9:31] Zero Linden: which needs to say which grid
[9:32] Zero Linden: I think you are absolutely right about how such things need to work in the future
[9:32] Neas Bade: but I really really really think that keeping with that design point is so fundamentally limitting that it has to change in the future
[9:32] Neas Bade: and the sooner the better
[9:32] Neas Bade: as it is a very clear early interop issue between multiple grids
[9:32] Zero Linden: I just think we should assume that there will be a new scheme than secondlife:///
[9:33] Zero Linden: well all
[9:33] Zero Linden: I'm now late for my next meeting
[9:33] Zero Linden: good stuff here
[9:33] Kri Ayakashi: well the old scheme could implictly assume linden grid as the default for some time to give everyone some space to adapt to new scheme
[9:33] Neas Bade: thanks zero, great talking with you :)
[9:33] Zero Linden: I guess I'll put this up in the wiki
[9:33] Rex Cronon: bye zero
[9:33] Zero Linden: thanks for coming
[9:33] Zero Linden: great discussions - all of 'em!
[9:33] Tao Takashi: thanks for hosting!
[9:33] Zero Linden: bye
[9:33] Tao Takashi: cya!
[9:33] Zha Ewry: Thanks zeor, lets docu ment that its choing to change, then
[9:33] Kri Ayakashi: bye Zero