User:Zero Linden/Office Hours/2008 Apr 01

From Second Life Wiki
Jump to: navigation, search
  • [13:04] Gesture Male: - Hey is missing from database.
  • [13:04] Teleport completed: from [1]
  • [13:05] Zha Ewry: Lovely gray texurtures Zero
  • [13:05] Zero Linden: are we ready for Mars? [2]
  • [13:05] Saijanai Kuhn: Zero I gots lots of nagging detail questions about SLGOGP for you
  • [13:05] Gareth Ellison: can we dive to business?
  • [13:05] Zha Ewry: did the test
  • [13:05] Zha Ewry: and didnt make it, but they offered my a chance to submit a youtube
  • [13:05] Gareth Ellison: would like to throw up the issue of that auto-generating code+docs from XML thing again
  • [13:05] Rex Cronon: oh, it works. thanks copilo
  • [13:05] Kopilo Hallard: np
  • [13:06] Tree Kyomoon: wow mars looks neat
  • [13:06] Kopilo Hallard: admires the skeleton
  • [13:06] Morgaine Dinova: Zero: funny that you should mention Mars, because we were just talking in Groupies about the need to embrace a wider coordinate system than SL has for interop, since not all linked worlds are going to be Flatlands :-)
  • [13:06] Gareth Ellison: heh, can we get a structured agenda of sorts? Zero?
  • [13:06] Kopilo Hallard: /disagree
  • [13:06] Saijanai Kuhn: Morgaine check out Signpost's map PAI he goes into detail about that I think
  • [13:07] Saijanai Kuhn: map API*
  • [13:07] Tao Takashi: Zero: heh :)
  • [13:07] Saijanai Kuhn: Zero?
  • [13:07] Zero Linden: yes
  • [13:07] Zero Linden: yes
  • [13:08] Zero Linden: Okay - well, I don't have a structured agenda for today --- but let's try this from now on
  • [13:08] Zero Linden: I'm going to create - now - a section on my web page for agenda items
  • [13:08] Gareth Ellison: wow
  • [13:08] Zero Linden: And then I can organize from there.
  • [13:08] Gareth Ellison: i was just thinking of listing in chat briefly what to cover today
  • [13:09] Zero Linden: that too is fine for today
  • [13:09] Gareth Ellison: ok :)
  • [13:09] Zero Linden: <booming voice> Call for agenda items..... Now! </booming voice>
  • [13:09] Gareth Ellison: nice idea to dump something on the wiki on User:ZeroLinden
  • [13:09] Gareth Ellison: ok, i have one
  • [13:09] Tao Takashi: lets cover my 165 point plan I prepared for today ;-)
  • [13:09] Saijanai Kuhn: SLGOGP details
  • [13:09] Gareth Ellison: auto-generating code + docs for all resources in the the new specs
  • [13:09] Morgaine Dinova: 1) Interop with non-SL-like wolds
  • [13:09] Saijanai Kuhn: agenda item
  • [13:09] Gareth Ellison: from an XML file
  • [13:10] Tao Takashi: are there non-SL like worlds? :)
  • [13:10] Saijanai Kuhn: me first, its fast and easy
  • [13:10] Tree Kyomoon: 1) controls to limit camera and movement for game developers who own sims
  • [13:10] Morgaine Dinova: Tao: no, but we're designing interop for tomorrow, not for today :-) And lots of people want planets, it's been discussed for ages
  • [13:10] Arawn Spitteler: Could we teleport into a torus? That's simply teleporting into a torus
  • [13:10] Tree Kyomoon: 2) access to HTTP headers in LLscript
  • [13:11] Gareth Ellison: heh - Tree - on 1 you just need a nicer client which sims can instruct
  • [13:11] Saijanai Kuhn: a consistent way to designate teh source/destination of resources in teh SLGOGP for both the table and the prose portion
  • [13:11] Saijanai Kuhn: https://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Rez_Avatar_Capability
  • [13:11] Gareth Ellison: my idea was tied in with what saijanai just raised
  • [13:11] Morgaine Dinova: Tree: such controls are not possible **on the camera**, since the client can do anything. The only way to limit visibility is by not sending objects from the server.
  • [13:12] Gareth Ellison: automate all the documentation, throw in where it flows to/from into that XML spec
  • [13:12] Gareth Ellison: morgaine - suggestions
  • [13:12] Gareth Ellison: not controls
  • [13:12] Saijanai Kuhn: Gareth, sounds great, but we gotta decide what goes into the spec...
  • [13:12] Tree Kyomoon: nothing is not possible
  • [13:12] Gareth Ellison: saijanai - have a field which specifies which component requests and which responds
  • [13:12] Gareth Ellison: or multiple such fields
  • [13:12] Gareth Ellison: in an array
  • [13:12] Gareth Ellison: i can see the XML in my head
  • [13:13] Saijanai Kuhn: thats what I have in the table. We need a similar thing for the prose and for Zero to sign off on it
  • [13:13] Zero Linden: Okay -
  • [13:13] Zero Linden: I have
  • [13:13] Zero Linden: 1) SLGOGP details 2) Generating docs & code from XML 3) Interop with non-SL-like worlds 4) controls for limiting camera 5) HTTP headers from LSL
  • [13:13] Zero Linden: So - let's take those in turn -- I'll be rude and call "TIME" when we need to move on
  • [13:13] Morgaine Dinova: Tree: it can be advisary, like Gareth suggests, but it can't be enforced unless you don't send down the objects at all. It's a similar situation to the Fallacy of DRM --- you can't send Bob something, and then expect him not to have it.
  • [13:13] Gareth Ellison: i'd argue 1 and 2 are part of the same (since saijanai's point lead onto mine)
  • [13:13] Gareth Ellison: but yeah
  • [13:14] Zero Linden: May be, but let's begin
  • [13:14] Zero Linden: welcome everyone to my office hours
  • [13:14] Zero Linden: all on the record, (thanks tree!) and so speak freely
  • [13:14] Saijanai Kuhn: Zero, teh backfround was Tes asked me to fit the strawman rez_avatar into the SLGOGP format and I ran into a snag
  • [13:14] Zero Linden: We'll start with SLGOGP
  • [13:14] Zero Linden: oh?
  • [13:15] Zero Linden: was the snag that you don't have all the XML/XSLT files needed?
  • [13:15] Saijanai Kuhn: well, its obvious from context that rez avatar starts with client <->agent and then moves to agent <-> region but we need an explicit place to make that clear in the table on the prose portion (IMHO)
  • [13:15] Gareth Ellison: heh, i can see 2 parts to that issue - first we don't know authoratively what resources have requests/responses flowing where for the most part
  • [13:15] Gareth Ellison: we have common sense, but not solid definitions
  • [13:15] Gareth Ellison: in those little tables
  • [13:15] Saijanai Kuhn: https://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Rez_Avatar_Capability I added a table entry for it
  • [13:16] Saijanai Kuhn: something LIKE that needs to be explicit, I think
  • [13:16] Saijanai Kuhn: and in the prose portion as well
  • [13:16] Zero Linden: I see, the things with the arrows, under the title
  • [13:16] Gareth Ellison: before with AW Groupies there was talk briefly of formatting for RFC eventually
  • [13:16] Saijanai Kuhn: I'm not commited to the format, just to the info
  • [13:17] Gareth Ellison: so the table layout should ideally fit into the anal RFC standards
  • [13:17] Gareth Ellison: the main thing though is making sure that it's all listed in format X
  • [13:17] Zero Linden: We can XSLT from XML Specification format into RFC2629 in the future, if IETF is the eventual locale of the work
  • [13:17] Gareth Ellison: in a strict definition
  • [13:17] Gareth Ellison: then proposed format X be XML, and we auto-generate base classes for language X at the same time as documentation
  • [13:18] Gareth Ellison: throw all the message/resource definitions out in HTML or similar format
  • [13:18] Saijanai Kuhn: right now, the context of the source/dest transaction is in the URL, but in the case of the second table, I don't have a URL definition yet
  • [13:18] Gareth Ellison: and then throw out basic skeleton code too
  • [13:18] Saijanai Kuhn: so there's no consistent way of saying what kind of transaction it will be
  • [13:18] Zero Linden: So, Saijanai
  • [13:18] Zero Linden: I'd list your first 'arrow diagram' as viewer --> agent Host
  • [13:18] Kopilo Hallard: *waves sorry need to run*
  • [13:19] Saijanai Kuhn: OK
  • [13:19] Zero Linden: sonce resource invocation is asymetric, we shouldn't use bidrectional arrows
  • [13:19] Rex Cronon: bye kopilo
  • [13:19] Gareth Ellison: silly minor thing, how about 2 fields instead of 1
  • [13:19] Gareth Ellison: source and dest
  • [13:19] Zero Linden: so we can use the > to "poitn" to the side providing the resource, and being invoked
  • [13:19] Gareth Ellison: just to make it more easily convert to machine-readable form
  • [13:19] Saijanai Kuhn: of course with long polls this becomes problemantic.
  • [13:20] Zero Linden: the URL field, seems correct - it is a capability on the agent host -- which should convey at least half that info
  • [13:20] Zero Linden: (since, in some sense, the capability doens't care who is actually invoking it)
  • [13:20] Gareth Ellison: hmm, a single operator like that "source > dest" with the > operator sounds good
  • [13:20] Zero Linden: The second one would be
  • [13:20] Gareth Ellison: we do need a general definition of who's invoking it
  • [13:20] Zero Linden: agent host --> region host
  • [13:20] Zero Linden: and the url would be "well known region url"
  • [13:20] Gareth Ellison: there could be a ruleset
  • [13:20] Gareth Ellison: a simple one
  • [13:20] Saijanai Kuhn: great. Now for the prose
  • [13:21] Gareth Ellison: "anyone can send this anywhere"
  • [13:21] Zero Linden: or, rather "capability from region host"
  • [13:21] Gareth Ellison: "anyone can send this to component X"
  • [13:21] Gareth Ellison: "anyone can serve this to component X"
  • [13:21] Gareth Ellison: etc
  • [13:21] Gareth Ellison: or "only X sends this to Y"
  • [13:21] Gareth Ellison: the latter being with the > operator
  • [13:22] Gareth Ellison: *>*
  • [13:22] Gareth Ellison: X>*
  • [13:22] Gareth Ellison: X>Y
  • [13:22] Gareth Ellison: looks like a sane notation
  • [13:22] Saijanai Kuhn: I'd go with -->
  • [13:22] Saijanai Kuhn: keeps with UML
  • [13:22] Gareth Ellison: heh, so long as it's uniform and parsable
  • [13:22] Gareth Ellison: though i'd still spit out those human-readable tables from an XML file
  • [13:23] Gareth Ellison: and do these little aesthetic/cosmetic changes at that point
  • [13:23] Zero Linden: Gareth - I point you at the XML Specification schema and info --- it includes a full IDL sub-langauge which I didn't use
  • [13:23] Saijanai Kuhn: OK, so source --> dest or something similar. For the prose section, we would use...?
  • [13:23] Zero Linden: you may want to look at that and see if you think it could be adapted to our use
  • [13:23] Gareth Ellison: Zero - will do so
  • [13:23] Gareth Ellison: i may have a go at throwing out a quick and dirty mulib implementation
  • [13:23] Zero Linden: Do you mean prose in the table it self, or when discussing it in running text?
  • [13:24] Saijanai Kuhn: running text
  • [13:24] Gareth Ellison: tell donovan btw that he has a 1-member fanclub
  • [13:24] Zero Linden: Hmm... "This resource is provided by the agent domain...."
  • [13:24] Saijanai Kuhn: My idea is that some peole will scan tables and ignroe the text and others will look at the text and ignore the table
  • [13:24] Saijanai Kuhn: OK fine
  • [13:24] Zero Linden: or "The viewer invokes this resource on the agend domain"
  • [13:24] Gareth Ellison: so you need the same info redundant in both to an extent saijanai?
  • [13:24] Saijanai Kuhn: though.... yeah, the second is more descriptive and explicit
  • [13:25] Gareth Ellison: how about going nuts and even auto-generating the prose?
  • [13:25] Saijanai Kuhn: the way Zero hsa it set up, he makes reference to the text if its a convolluted message and/or response. SO to keep consistent, we should have the info in both forms
  • [13:25] Morgaine Dinova: Shouldn't be hard to make a "BNF for Protocols" ... just a BNF extended with the notion of n parties who exchange the BNF-specified communication.
  • [13:25] Zero Linden: No, I think that might be overkill
  • [13:26] Zero Linden: That is, generating prose...
  • [13:26] Saijanai Kuhn: we should have a BNF for terms but I dont' see a need to go to the protocol level
  • [13:26] Gareth Ellison: Zero - BNF or generating prose?
  • [13:26] Gareth Ellison: ah
  • [13:26] Zero Linden: remember, the prose is there for humans to read and to make clear - and is probably best left to humans to write
  • [13:26] Gareth Ellison: just think of it as the ultimate in DRY
  • [13:27] Zero Linden: I think the mechancial details can be generated
  • [13:27] Zero Linden: like bindings
  • [13:27] Gareth Ellison: you just annotate each field and it's purpose, give a purpose of what the individual resource does and misc notes
  • [13:27] Saijanai Kuhn: sure the table is one thing. THe nicely worded sentences probably need a human hand regardless if they're generated or not so
  • [13:27] Gareth Ellison: throw it all together into a paragraph
  • [13:28] Gareth Ellison: if it's too nuts then excuse me
  • [13:28] Zero Linden: This is going to take some time to get right - I think it will take about a dozen resource classes before we are comfortable
  • [13:28] Zero Linden: with the style and manner.
  • [13:28] Zha Ewry: nods
  • [13:28] Saijanai Kuhn: right now, the resource has: prose, then table with "see prose" if the table would get to wordy
  • [13:28] Morgaine Dinova: Another good reason for keeping BNF and other grammar-based approaches in mind is that we can then write formal protocol verifiers, very fast ones for on-the-wire use.
  • [13:28] Gareth Ellison: hence the uber-DRY i proposed :)
  • [13:29] Gareth Ellison: lots of resource classes == lots of redundant prose+table
  • [13:29] Zha Ewry: A tinty part of me would whisper, get the XML schema right, and start there, but I'll try and keep that voice silent
  • [13:29] Zero Linden: Morgaine - if you can see if you can find some good protocol BNF systems and report back, that would be great
  • [13:29] Dahlia Trimble: nods at Zha
  • [13:29] Reed Steamroller: adios
  • [13:30] Zero Linden: I also looked into UML Sequence diagrams, as suggested last week
  • [13:30] Zha Ewry: perks up
  • [13:31] Gareth Ellison: everytime UML is mentioned i have memories of college :(
  • [13:31] Zero Linden: They seem a good vechicle for exposition, in both the spec. itself and a "annotated" document
  • [13:31] Morgaine Dinova: Zero: I'm an old hand at writing parsers for languages, but I've not seen one for protocols specifically (except in bursts on the output of each party).
  • [13:31] Saijanai Kuhn: Found this reference list of networking sequence diagrams, BTW: [3]
  • [13:31] Zha Ewry: nods
  • [13:31] Gareth Ellison: morgaine - a text-based protocol IS a language
  • [13:31] Zero Linden: BUT, I didn't find many clear choices for open, easy tools for building them
  • [13:31] Gareth Ellison: just needs faster realtime parsing
  • [13:32] Zha Ewry: They are pretty reasonable in expresiveness, without being too heay
  • [13:32] Zha Ewry: nods
  • [13:32] Zero Linden: or a and XML scheme, short fo the entire XNI scheme for all of UML (which seemed, on reading about it, large, hard, and not fully or correctly implemented often)
  • [13:32] Zha Ewry: We really want a tool across linux, mac, windows
  • [13:32] Zero Linden: And preferably a simple XML schema for expressing them
  • [13:32] Saijanai Kuhn: Umbrello is allegedly crossplatform but I haven't compiled it yet
  • [13:33] Zero Linden: See - now, things which people have to compile before using.... while it does present a sort of litmus test... it is limiting
  • [13:33] Zha Ewry: Yeah, that would be ideal, Zero, tho, I'd bend on it for a good 3 platform tool
  • [13:33] Morgaine Dinova: Gareth: "a text-based protocol IS a language" for a very loose meaning of "language", yes :-)
  • [13:33] Gareth Ellison: morgaine - what i meant is that it's a medium of expressing something
  • [13:34] Gareth Ellison: rather than expressing executable instructions though, it expresses communication
  • [13:34] Zha Ewry: ducks the dueling tuatologies
  • [13:34] Gareth Ellison: heh
  • [13:34] Saijanai Kuhn: looks glassy eyed.
  • [13:34] Tree Kyomoon: academic
  • [13:34] Tree Kyomoon: wheres the beef
  • [13:35] Morgaine Dinova: Gareth: yeah, but what we're trying to do here is to formalize a protocol, not to create a medium of expression
  • [13:35] Saijanai Kuhn: anyway, I have plenty of choices for hand-crafting UML and can fudge sequence diagrams with cute numbers. THe real question is what shoudl they look like?
  • [13:35] Gareth Ellison: heh, i halt the derailment train
  • [13:35] Zero Linden: Oooooooookay - so, yes, we are in the land of meta - looking for a formal langauge to specify our protocol which is a formal language....
  • [13:35] Saijanai Kuhn: for example, I couldn't find a UML sequence diagram of a long poll anywhere
  • [13:35] Gareth Ellison: parsers for text-based languages if fast can do text-based protocols too
  • [13:36] Gareth Ellison: i've got a little protocol i use for various tasks which is stupidly simple
  • [13:36] Morgaine Dinova: Gareth: I thought you were stopping your derailment ;-)
  • [13:36] Gareth Ellison: FIELD1:FIELD2:FIELD3
  • [13:36] Gareth Ellison: sorry
  • [13:36] Saijanai Kuhn: mutters about UML diagrams being more ontopic
  • [13:36] Monalisa Robbiani: whats going on here
  • [13:36] Zero Linden: hmmmmm.....
  • [13:36] Zero Linden: so - let's not get into the
  • [13:37] Saijanai Kuhn: Monalisa we're having an uber-geek discussion about second life programming at the most nitty gritty details
  • [13:37] Zero Linden: pit of *HOW* we build UML diagrams
  • [13:37] Monalisa Robbiani: o.O
  • [13:37] Gareth Ellison: hmm, do we need diagrams for a spec?
  • [13:37] Zero Linden: Instead, let's see if anyone can, this week come up with a good UML diagrm of event queue
  • [13:37] Rex Cronon: using a UML editor?
  • [13:37] Zero Linden: and report back how they did it
  • [13:37] Gareth Ellison: such highly detailed diagrams - do we need them?
  • [13:38] Saijanai Kuhn: I had a simple shorthand I'd like to proplse client <---->----- server
  • [13:38] Rex Cronon: wouldn't a flow chart be good?
  • [13:38] Zero Linden: Or - any other representation - let's get some real examples in front of us and we can discuss
  • [13:38] Zero Linden: bring your textures and/or notecards next week?
  • [13:38] Saijanai Kuhn: Tao did a simple sequence diagram for login with caps.
  • [13:39] Gareth Ellison: does running code count?
  • [13:39] Zero Linden: ONly if you think it helps the exposition!
  • [13:39] Zero Linden: So, three line Forth implementations, or one line APL -- no
  • [13:39] Gareth Ellison: various little skeleton things
  • [13:39] Gareth Ellison: in python
  • [13:39] Gareth Ellison: well commented and all that
  • [13:40] Saijanai Kuhn: [4] simple caps based login sequence diagram
  • [13:40] Zero Linden: .....BZZZZIP --- TIME -
  • [13:40] Zero Linden: time to move on to the next item, we can readdress this next week
  • [13:40] Rex Cronon: what r the choices of free UML editors?
  • [13:40] Morgaine Dinova: Cool
  • [13:41] Gareth Ellison: buzz rex
  • [13:41] Saijanai Kuhn: KK got my most important thing cleared up thanks zero and all for being patient
  • [13:41] Zero Linden: So
  • [13:41] Zero Linden: 3) Interop with non-SL-like worlds
  • [13:41] Saijanai Kuhn: rex just google for UML software and look for the freebies and demos
  • [13:41] Zero Linden: Now - this is a potentially very very big issue
  • [13:41] Gareth Ellison: planet-type geography i think was the idea
  • [13:42] Zero Linden: and potentially unbounded
  • [13:42] Morgaine Dinova: The idea was simply to avoid hardwiring in SL-centric ideas into the protocol, in those areas where no such restrictions are required.
  • [13:42] Zero Linden: So - let me ask, what axes of non-SL-like were being raised here? Just map topology?
  • [13:42] Zha Ewry: Running code, is almost nevr
  • [13:42] Zha Ewry: useful, in terms of defining a protoocl
  • [13:43] Zha Ewry: At best, it helps capture on portion of the state machine, and not all of them
  • [13:43] Rex Cronon: each one has different capabilities. shouldn't everybody use only those that have similar capabilities?
  • [13:43] Tree Kyomoon: perhaps this one relates to what I was talking about. In many games, you have the camera attached to the avatar and that makes the game more compelling/immersive. Mabey we could have a control on an island that would lock cameras to avatars?
  • [13:44] Zero Linden: Tree, let's hold that for a moment... it's still on my agenda
  • [13:44] Zha Ewry: its totally ubounded
  • [13:44] Zha Ewry: Starts with things like prim types and geometry
  • [13:44] Morgaine Dinova: Zero: for example, in the area of topology, connecting to a region shouldn't make any assumptions about its extent or physics or dimernsionality.
  • [13:44] Saijanai Kuhn: rex RrealXtend and openviewer have the goal of beeing swissarmyknife viewers
  • [13:44] Charlesk Bing: Zero. Perhaps you can describe some of your recent thoughts with respect to OpenSim?
  • [13:44] Zha Ewry: and goes all the way down to things like whether there are even viewable avayars
  • [13:44] Gareth Ellison: same goes sim-side for opensim i believe saijnai :)
  • [13:44] Morgaine Dinova: We can expect 3rd party worlds to have planets, and ringworlds, and Dyson spheres for example.
  • [13:44] Zha Ewry: OpenSim, by comparison, asumes pretty much 90% overlap
  • [13:44] Zero Linden: So, the primary goal we have is to make a protocol that opens up the grid
  • [13:44] Rex Cronon: thanks sai
  • [13:45] Zero Linden: and to that aim, we have Second Life as it exists today as the model, and the feature set to match
  • [13:45] Zero Linden: Beyond that, we want to aim
  • [13:45] Morgaine Dinova: Zero: even the word "Grid" is wrong, since not all worlds will be 2D ttiled Flatlands
  • [13:45] Saijanai Kuhn: https://wiki.secondlife.com/wiki/AW_Groupies#External_Resources
  • [13:45] Charlesk Bing: +1 Zero, and in fact, the testing on OpenSim is with the official SecondLife client, currently 1.19.0.5
  • [13:46] Zero Linden: for being agnostic where we can, without compromising our ability to actually engineer a working system in the coming months
  • [13:46] Gareth Ellison: i'd think beyond a certain point you can't extend more without breaking the legacy stuff
  • [13:46] Gareth Ellison: need to have the newer stuff as just that - extensions
  • [13:46] Zha Ewry: reminds people that stepwise motion from the existing world is sort of required
  • [13:47] Saijanai Kuhn: it becomes a vewer-side issue unless you're trying to allow walk-trhough worlds
  • [13:47] Gareth Ellison: unless you use all kinds of proxying and protocol conversion in fancy schemes
  • [13:47] Saijanai Kuhn: and I think you can fudge that by having a border sim with SL compatiblity
  • [13:47] Zero Linden: We are always going to have to strike a balance between accomodating a future, and making something we can impleemnt soon
  • [13:47] Zha Ewry: and.. that as we get further fromt he legacy roots, the easier it gets tro volve some of it
  • [13:47] Gareth Ellison: but such schemes are software hacks, not protocol specs
  • [13:47] Dahlia Trimble: teleporting between worlds might be a good place to start
  • [13:47] Tao Takashi: I also would think that we should get some working version with the existing models first and then go from there
  • [13:47] Zero Linden: So - for example,
  • [13:47] Tree Kyomoon: seems to me this is the wrong approach. Let each world handle its own rules, SL should just make the HTTP Connectivity more robust and let the worlds/creators and users decide what needs to be communicated back and forth
  • [13:47] Zha Ewry: Long term, one can imagine richer ways of markign up things liek region shape/size
  • [13:48] Zha Ewry: but.. not allowing edge touches between wildly different tings
  • [13:48] Zero Linden: I don't think we will consider any protocol changes that would enable full rendering on the server side
  • [13:48] Tao Takashi: and once the protocol and many implementations are in place it should also be easier to invent new formats and experiment with them
  • [13:48] Morgaine Dinova: Zero: a totally different example: some worlds will have slightly different features in their agent domain oo, eg. they may want multiple first names per accountfor instance, so that each account is actually a family of diffrently named avatars sharing common resources.
  • [13:48] Tree Kyomoon: and, detach the viewer itself from the controls so it can be embedded in other technologies like html or shockwave or whatever
  • [13:48] Saijanai Kuhn: Tree, adjacent sims will require compatible visual protocols
  • [13:48] Zero Linden: It is just too far out, we don't konw what the rational use cases are, and no one knows how to effectively implementat that anyway
  • [13:48] Gareth Ellison: we need something akin to HTML+javascript/plugins
  • [13:48] Finrod Meriman: what do you think about alternative object formats... collada for example
  • [13:48] Zha Ewry: I don't know that you can avoid it, Zero. One coudld build a sim, which did some of that, and if it tlaked to the the other servcies correctly
  • [13:48] Saijanai Kuhn: so... for now, just assume border sims to push the issue onto the incompatible grid's side
  • [13:48] Zha Ewry: It *ought* to work
  • [13:49] Gareth Ellison: put in the holes where people can plugin what they want
  • [13:49] Tree Kyomoon: we do know what the most popular social networks and "pseudo virtual worlds" are, and they have pretty much nothing in common with SL
  • [13:49] Zero Linden: On the other hand, we should leave things in such a way that different domains can do different rules... like
  • [13:49] Tree Kyomoon: except they could communicate via HTTP
  • [13:49] Zero Linden: I'm pretty sure nothing in the protocol will enforce gravity of 1g
  • [13:49] Morgaine Dinova: Good. But what about altitude?
  • [13:50] Rex Cronon: why should gravity be enforced?
  • [13:50] Gareth Ellison: key point - allow new message types
  • [13:50] Saijanai Kuhn: BTW< in case anyone missed it (as I did), Havok is now free for non-commercial use
  • [13:50] Dahlia Trimble: w00t for no gravity! :D
  • [13:50] Gareth Ellison: that is absolutely key to enabling extra non-core features
  • [13:50] Zha Ewry: Well, you need to let the client know
  • [13:50] Zero Linden: O
  • [13:50] Zha Ewry: for dead reckoning
  • [13:50] Zha Ewry: but that's about it
  • [13:50] Zero Linden: So, of course we'll allow for future new resource classes (message types)
  • [13:50] Gareth Ellison: in fact, i'd argue for letting clients on the current grid send arbitary weird messages to each other
  • [13:50] Gareth Ellison: and that could be done today
  • [13:50] Gareth Ellison: with very little changes
  • [13:50] Morgaine Dinova: I think SL's Flatland is going to get us in trouble really soon, once others start experimenting with 3D space instead of SL's 2D tiling.
  • [13:51] Gareth Ellison: rather than silly IM hacks
  • [13:51] Zero Linden: but for example, on the first iteration, the object format isn't likely to change and so, for example, placement beyond a 768m may not be feasible
  • [13:51] Zero Linden: (or what every the limit in the protocol is currently)
  • [13:51] Dahlia Trimble: lol how about added dimensions
  • [13:51] Tree Kyomoon: detach viewer, shore up http functionality, and leave interop to the other developers IMHO
  • [13:51] Saijanai Kuhn: Gareth, with arbitraryweirddmesssagename, its doable right now. Just don't expect the standard client to do anything with it
  • [13:51] Zero Linden: but that doesn't preclude us from doing a new Objet Update message in the future
  • [13:51] Zha Ewry: I tend to agree with Morgaine on this, long term
  • [13:51] Zero Linden: On the other end of the spectrum
  • [13:51] Zha Ewry: That the 2d, square grid tesselation
  • [13:51] Zero Linden: I'
  • [13:51] Rex Cronon: zero, u build above 768 m in havok 4
  • [13:51] Zha Ewry: is pretty long term limiting
  • [13:51] Morgaine Dinova: Zero: why is plcement beyond 768m not feasible? That's your own specific limitation, and it should not be hardwired in.
  • [13:51] Zero Linden: I'd be against having the simulator send the viewer a tensor the describes the space geomtery
  • [13:52] Saijanai Kuhn: thought the new limit was 4096 with h4
  • [13:52] Zero Linden: It might be, I just think the packed object update message has a limiti on the number of bits used for z
  • [13:52] Zero Linden: and I don't remember off hand what it is
  • [13:52] Dahlia Trimble: has a skybox at 2000 in H1
  • [13:52] Zero Linden: I could be wrong -
  • [13:52] Gareth Ellison: saijanai - can you send weirdmessage to other users?
  • [13:53] Gareth Ellison: i.e relay between users
  • [13:53] Morgaine Dinova: Zero: well fine, but when it comes to ut looking at the coordinate format, we need to be sure that we don't retain SL's particular limits.
  • [13:53] Zero Linden: but that is the kind of thing that we can easily fix... sending object updates via LLSD encoding, will of course not hardwire in a limit
  • [13:53] Zero Linden: but I think it should hardwire in a limit of three dimensions
  • [13:53] Saijanai Kuhn: not via the client. You could send it to the server and the server could send one to the client but no P2P supported
  • [13:53] Zero Linden: hyper-cubes are just not worth supporting at this time
  • [13:53] Zha Ewry: I think, that we need to keep those firmly in mind, as we get rid of packing
  • [13:53] Gareth Ellison: heh, i meant "server, rebroadcast this"
  • [13:53] Zero Linden: since no one has a 4D virtual world or knows what we'd do with such a beast
  • [13:53] Zha Ewry: That we try hard to get to LLSD structs which are much less limited
  • [13:53] Gareth Ellison: and also let objects have arbitary weird metadata
  • [13:54] Zha Ewry: Rez this cube, in 1928, please
  • [13:54] Gareth Ellison: lol
  • [13:54] Arawn Spitteler: Fourth Dimension would be Region
  • [13:54] Zero Linden: Zha - rez'd already!
  • [13:54] Zha Ewry: looks for it
  • [13:54] Zha Ewry: Seems to have decayed away
  • [13:54] Saijanai Kuhn: goggles at time machine grid
  • [13:54] Dahlia Trimble: I was thinking more about the various privacy suggestions floating around
  • [13:54] Zha Ewry: grins at Dahlia
  • [13:54] Tree Kyomoon: seems like all this could just be left to developers as most of what SL does isnt done anywhere else
  • [13:54] Morgaine Dinova: Zero: agreed. Nobody has said they're building a hyper-D world yet, but loads of people want planetary worlds and space travel right now, so full 3D placement is not pie in the sky, it's a requirement.
  • [13:54] Zha Ewry: I think, that's a more interesting question, tho.. I am far from convinced that the right cure is pjhysical hacks
  • [13:55] Zha Ewry: The basmet trick is clever
  • [13:55] Zha Ewry: but.. it sort of only makes sense, becauee it's hard to go underground now
  • [13:55] Gareth Ellison: the basement is a great idea
  • [13:55] Gareth Ellison: lots of interesting builds could be made with that
  • [13:55] Zha Ewry: Only because negative ground is borked
  • [13:56] Zha Ewry: Really, if we want privacy?
  • [13:56] Zha Ewry: FIx the camera stuff
  • [13:56] Zha Ewry: Not, the world model
  • [13:56] Morgaine Dinova: Agent Stonecutter's "Parcel Basements" was the best privacy idea ever proposed ... unfortunately it can't work outside of SL's Flatland.
  • [13:56] Zero Linden: Right - I don't konw that anyone is building a region big enough to require spherical coordinate geometry, if that is what you are suggesting....
  • [13:56] Gareth Ellison: i sadly must leave you now
  • [13:56] Gareth Ellison: i'll idle for a bit.....
  • [13:56] Zero Linden: but wider range of Cartesian coordiantes - - sure
  • [13:56] Zha Ewry: The problem with it Morgaine, is that as, you point out, it borks up real basements
  • [13:57] Zero Linden: Okay, I ahve to go in 4 min.
  • [13:57] Zero Linden: so I call TIME
  • [13:57] Gareth Ellison: heh
  • [13:57] Zha Ewry: And. is only needed because of other issues which should be properly fixed
  • [13:57] Zero Linden: and want to address the last two items
  • [13:57] Gareth Ellison: good timing
  • [13:57] Morgaine Dinova: Zero: yes, planets and space travel assume spherical geometry :-)
  • [13:57] Zero Linden: 4) controls for limiting camera 5) HTTP headers from LSL
  • [13:57] Tree Kyomoon: yay!
  • [13:58] Zero Linden: The first strikes me as reasonable for us to have messages that have the region request certain camera prperties
  • [13:58] Zero Linden: of the viewer
  • [13:58] Zero Linden: but we have to recognize that there is no way to enforce that
  • [13:58] Morgaine Dinova: I am interested in Tree's topic too, but not for Tree's reason. I want the ability to turn off obects beeing streamed down for scalability purposes. He wants it for visibility
  • [13:58] Zero Linden: the viewer will always be able to push the camera where it chooses
  • [13:58] Zha Ewry: Only way to enfore that is to limit what you send
  • [13:59] Zero Linden: of course, the region doesn't have to send you geometery you don't want...
  • [13:59] Tree Kyomoon: right but a region could boot someone if they didnt meet camera stipulations
  • [13:59] Dahlia Trimble: unless the region controlled what was sent to the viewer so cameras would/wouldnt see it
  • [13:59] Zero Linden: Tree - a region won't know
  • [13:59] Zha Ewry: or.. not give them objects inthe region
  • [13:59] Morgaine Dinova: Tree; the client is open source. Live with it
  • [13:59] Zero Linden: there will be no way for a viewer to proove that it is respecting the camera constratings
  • [13:59] Zero Linden: but that said, I don't think that is a big deal ---
  • [13:59] Zha Ewry: The sim, tho can chose to not show yout banned objects
  • [13:59] Zero Linden: the point is get people the kind of experience they want
  • [14:00] Zero Linden: what we'll need here is feedback from people who've built such 3D expereinces to tell us what sort of
  • [14:00] Zero Linden: restrictions are functional and useful
  • [14:00] Morgaine Dinova: Zero: can we have capabilities tofilter out certain objects from being sent to us then, please?
  • [14:00] Tree Kyomoon: if I build an elaborate adventure on my sim, I want to control how peopel go through it or its pointless
  • [14:00] Dahlia Trimble: this is where the added dimension would help
  • [14:00] Rex Cronon: why not feedback from users?
  • [14:00] Tree Kyomoon: which is why a lot of interactive games cant be built here
  • [14:00] Zero Linden: Right - but we need experienced 3D experience designers totell us what form those restrictions take.
  • [14:01] Saijanai Kuhn: Goes back to the capabilities tree idea but for objects, not categories
  • [14:01] Tree Kyomoon: why not give some folks at CYAN a call? They need a new place to build myst, this would be perfect!
  • [14:01] Zero Linden: Rex - where those users are creating such experiences, sure --- I'm a user, and a technicological one, and I could *guess* as a useful set of camera restriction messages.....
  • [14:01] Zero Linden: ....but I don't trust my intuition here at all
  • [14:02] Tree Kyomoon: anyway, also having more control over preloading things would be helpful for games
  • [14:02] Tree Kyomoon: and interactive simulations
  • [14:02] Zero Linden: As for headers on LSL -- that speaks to our need, as some point, to tackle the formal defintion of the LSL library
  • [14:02] Tree Kyomoon: like, load orders
  • [14:02] Saijanai Kuhn: I think there are two issues: 1) get poeple itnerested i contributing 2) get them to udnerstand what you want them to contribute
  • [14:02] Zero Linden: which - will be a big job
  • [14:02] Morgaine Dinova: Zero: given object filtering capabilities, Tree's sim could stop download of certain objects until the client has passed some hurdle. And for scalability, the same controls could be used to prevent unnecessarily details from being downloaded.
  • [14:03] Zero Linden: Tree- I think preload will be a sim side implemetation detail --- since the sim gets to choose what to send
  • [14:03] Saijanai Kuhn: Zer, but we still need some kind of hierarchy of capabilities or something along that line
  • [14:03] Zero Linden: Morgaine - I hope taht we can define the protocol in such a way that rather than such filters being part of the protocol, they can be implementation choices on the part of a sim implemetnation
  • [14:03] Tree Kyomoon: well preload and camera limits are basically why Ive been unable to recreate e-learning experiences here, and HTTP headers as well for interop with our content management systesm
  • [14:04] Saijanai Kuhn: what the hierachy loks like might be implementation dependent. That such hierarchies CAN exist needs to be part of the protocol
  • [14:04] Zero Linden: Oh dear - it is 1403 -- an amusing, but large IBM band printer
  • [14:04] Zero Linden: from the 60s
  • [14:04] Tree Kyomoon: not to mention lack of arrays. If those 4 things were in, I could build limitless numbers of high value e-learning and games
  • [14:04] Zha Ewry: /And time for my 1400 meeting
  • [14:05] Zha Ewry: /em lifts her lid and drops a coffee mug on the floor and TPs
  • [14:05] Saijanai Kuhn: hey two meaty meetings in one day in SL-- what's up with that?
  • [14:05] Zero Linden: you could code it to make different noises through the pattern of characters you printed on the page
  • [14:05] Aphilo Aarde: Thank you, Zero!
  • [14:05] Zero Linden: i
  • [14:05] Zha Ewry: Thanks all
  • [14:05] Morgaine Dinova: Sai: I support that point. The fact that objects hierarchies exist should be part of the protocol#
  • [14:05] Zero Linden: and if you printered the same sequence as was on the band, all the hammers fired at once and the printer visible shook
  • [14:05] Dahlia Trimble: Thanks Zero/all :)
  • [14:05] Morgaine Dinova: Cya Zero!