User:Zero Linden/Office Hours/2007 Mar 06

Transcript of Zero Linden's office hours:

[13:01]	Maxx Duell accepted your inventory offer.
[13:01]	Zha Ewry:	Hello Zero!
[13:01]	Zero Linden decline Volunteer Auditorium, Pro Racer (189, 124, 25) from A group member named Amber Linden.
[13:01]	Dale Innis:	Hi hi!
[13:01]	Jason Ayakashi:	hi, zero
[13:01]	Zero Linden:	hello hello
[13:02]	Hiro Market:	hi zero
[13:02]	Dale Innis apologized for suddenly running off in a few minutes. :)
[13:02]	Dale Innis:	(apologizes)
[13:02]	Zero Linden:	Welcome all
[13:02]	Zha Ewry:	Hey Rex, welcome back
[13:02]	Rex Cronon:	hello everybody
[13:03]	Zero Linden:	Everyone had a good weekend?
[13:03]	Dale Innis:	Even slept some. :)
[13:03]	Zero Linden:	I spent far too much of mine thinking about cross-protocol endpoints.
[13:03]	Dale Innis:	lol
[13:03]	Zha Ewry:	eewe
[13:04]	Zha Ewry dislkies m*n problems
[13:04]	Zha Ewry:	Hello Vitis
[13:04]	Rex Cronon:	the things just started here right?
[13:04]	Vitis Obviate:	Heya
[13:04]	Rex Cronon:	hi
[13:04]	Zha Ewry:	Zero has even done his "ground rules" yet
[13:04]	Zero Linden:	Yes - and who would have thought that a simple concept like "the sender of this message" could have such a property?!?!?
[13:04]	Zha Ewry would :-)
[13:04]	Zero Linden:	Yes, things are just started, Rez
[13:05]	Zero Linden:	wow - big turn out today!
[13:05]	flying ball whispers: I am ALIVE!
[13:05]	Sifu Moraga:	Gotta load my cache....
[13:05]	flying ball:	, you can't sit on me![cd]
[13:05]	flying ball whispers: I am ALIVE!
[13:06]	Dale Innis:	:) yeah some of us will be running of momentarily.
[13:06]	Dale Innis:	(off)
[13:06]	Sifu Moraga:	I'll be falling asleep in a moment
[13:06]	Zero Linden:	Well - as most of you know, but protocol dictate I say....
[13:06]	Zero Linden:	This is Zero's Techno-Geek-Fest office hours
[13:06]	Zero Linden:	And it the transcripts will be posted to the SL wiki
[13:07]	Sifu Moraga:	Oops, a lot of IBMers here
[13:07]	Zero Linden:	Unlike last session - I have nothing in particular on the agenda to talk about..... though I'll give a brief update
[13:08]	Zha Ewry:	Good, then I can pester you about in / out blobs
[13:08]	C4 (say /5 boom): Ka-Boom
[13:08]	Zero Linden:	Last Thursday we were walking about a sim where almost all the sim traffice to the viewer went over LLSD, via the event queue, via a capability
[13:09]	Zero Linden:	That was a good milestone. We hope this week to have a grid up where the only traffic that is UDP are some messages like ObjectUpdate and the rest
[13:09]	Zero Linden:	of the servers are all talking LLSD over some TCP based transport, as well as the viewer to sim communications
[13:09]	josserand Jacobus:	Hi very nice place, Zha ! May I sit down ?
[13:09]	Zero Linden:	That's all from me
[13:09]	Zero Linden:	So, I'm happy to talk blobs
[13:10]	Zero Linden:	For those that don't know, there is a Zero Office Hour Discussion page in the wiki
[13:10]	Hiro Market:	can i just request the wiki for the last session is updated with the diagrams
[13:10]	Zero Linden:	https://wiki.secondlife.com/wiki/Discussion_Page_for_Zero_Linden%27s_Office_Hours
[13:10]	Hiro Market:	missing atm
[13:10]	Zha Ewry:	Good. How much pain would it cause to have bigger than 2K objects come in as blobs?
[13:10]	Vitis Obviate:	ahh..images are up...ty
[13:10]	Zero Linden:	Hiro - what? https://wiki.secondlife.com/wiki/ZeroTranscript2007Mar01 has images
[13:10]	Sifu Moraga:	(and then you'd have to decide how to store them)
[13:10]	Zha Ewry:	I'm especially keen on the idea, as that gets us out of the LSL data space problems
[13:11]	Zha Ewry:	As to where Sifu, in inventory, inside the script's prim, is one easy thought
[13:11]	Dale Innis:	Yeah; get everyone to store the big stuff on their own external srevers! I like that. :)
[13:11]	josserand Jacobus:	No answer so I sit down
[13:11]	Zha Ewry:	Because, you don't want them to be live, without some effort on the part of the scripter
[13:11]	Sifu Moraga:	I currently use notecards for blobs
[13:11]	Hiro Market:	no, nothing for me, tried opera and ie
[13:12]	Zero Linden:	So, for others, if you haven't read it, you might want to bop on over to the wiki discussion page and read Zha's proposal
[13:12]	Zero Linden:	Sifu - right, but notecards arent r/w and aren't likely to be.... ever.
[13:12]	Sifu Moraga:	yes, notecards are a real pain
[13:12]	josserand Jacobus:	Zero, what mean LindenVillager please
[13:12]	Sifu Moraga:	but they were all we could get to work
[13:12]	Dale Innis:	Hence the desire for more general blobs. :)
[13:12]	Zha Ewry:	Hmm. Before we dive to far, why aren't notecards writable?
[13:12]	Rex Cronon:	a link to zha proposal is on you page zero?
[13:12]	Sifu Moraga:	exactly
[13:12]	Zero Linden:	Hiro - does this work for you: https://wiki.secondlife.com/wiki/Image:ZeroOfficeHours-20070301-slide1.png ??
[13:13]	Zha Ewry:	https://wiki.secondlife.com/wiki/Discussion_Page_for_Zero_Linden%27s_Office_Hours
[13:13]	Zero Linden:	https://wiki.secondlife.com/wiki/Discussion_Page_for_Zero_Linden%27s_Office_Hours#Binary_Blob_in.2Fout_from_SL
[13:13]	Zha Ewry:	If you use mine, scroll down, Zero's is more precise
[13:13]	Zero Linden:	So
[13:13]	Zero Linden:	there are two aspects about blobs I'd like to discuss
[13:14]	Zero Linden:	First - mechanics of what blobs would look like:
[13:15]	Zero Linden:	Right now, the inventory of an object is essentially a list of assets and access rights information
[13:15]	Zero Linden:	A binary blob, especially a r/w one could not be stored in the asset server becuase the asset server
[13:15]	Zero Linden:	(not a single machine, but logically so), was designed, and is cached, on the assumption that
[13:15]	Zero Linden:	assets are data that never change once written
[13:16]	Zha Ewry:	I'd assume you'd take it into a native SL type inbound
[13:16]	Sifu Moraga:	Hmmm, I see the problem
[13:16]	Zha Ewry:	So, the mime type of the blob would tell the inbound process how to turn it into an SL object, you'ddump it into the asset server
[13:16]	Zero Linden:	but nonetheless, we'd have to extend the concept of inventory to include objects that aren't assets.
[13:16]	Zha Ewry:	and the pass the uuid to the invenotry of the prim running the script
[13:16]	Sifu Moraga:	yes
[13:16]	Zero Linden:	Not impossible, but definitely different
[13:17]	Zero Linden:	And once one wants all the inventory like operations to work on them - you see that we'd be effectively trying to
[13:17]	Zha Ewry:	thus it becomes a fairly normal SL object, before it gets into the asset server
[13:17]	Zero Linden:	create a sub-class of an abstract class (inventory item) that doesn't currently exist
[13:17]	Sifu Moraga:	Since an object is local to a sim, could transitory blobs be stored by the sim server?
[13:17]	Zero Linden:	Sifu - it would have to be -- so
[13:18]	Zero Linden:	right now, when we move an inventory item (or copy it), there is no data movement at all, becuase the assent doesn't change or move
[13:18]	Sifu Moraga:	Ko, so the problem is that an object can reference anything that is not in the asset server
[13:18]	Zha Ewry:	right, you just move a uuid
[13:18]	Zero Linden:	for a blob, we'd have to hook all those and do copying and/or moving and/or reference counting.... etc...
[13:18]	Zero Linden:	none of this is impossible, just more difficult and involves a refactoring of a part of the system
[13:19]	Zha Ewry:	Well, you actually looked at amore general solution... II won't complain if you do that... mind you
[13:19]	Zha Ewry:	I'd be happy to have a mim driven way of getting blobbed assets into the asset server, and into the inventory of a local object
[13:19]	Zero Linden:	So now we have to store that data too... and as Sifu said, it would be on the sim... some of the time
[13:19]	Sifu Moraga thinks out loud, could an object store a reference to a transient object?
[13:19]	Zero Linden:	so - when you take an object into inventory (take or take copy), we are basically saving the state of the object (and scripts), and the inventory list, and writing that into a new asset
[13:20]	Zha Ewry:	I'd asume you'd be reluctant to do to much of that, as you now have state which is in a bad way, if the sim crashes
[13:20]	Zero Linden:	So in this case, we'd have to bundle all the data of the blob up into the inventory entry and store that too
[13:20]	Zha Ewry:	right now, assets either are, or don't exist. Not much inbetween
[13:20]	Zero Linden:	again, not difficult, but more work to do.... and more data to move
[13:20]	Vitis Obviate reflects that we should discuss the "why can't we write notecards" problem also - as Zha suggested - before we dive too deep
[13:20]	Zha Ewry:	In the asset server, with a uuid, or non-existent
[13:21]	Zero Linden:	Internally, if the object is rezz'd we'd have to have the data hanging off the inventory item... again not hard
[13:21]	Zero Linden:	and when the sim state saves, we have to write out all that data with objects in the same way as when sent to the asset server during Take
[13:21]	Zero Linden:	So these changes wouldn't be that hard.. easier than the inventory operation refactoring, actually
[13:22]	Zero Linden:	But - then there is the issue of the data and the cost of storing it and moving it around
[13:22]	Zha Ewry:	Vitis, I think you just got a big chunk of your answer to read/write notecard, btw
[13:22]	Zha Ewry:	Since the same issiues, roughtly obtain
[13:22]	Zha Ewry:	(lots of state, and the question of the UUIDs of the notecard in each state)
[13:22]	Zero Linden:	If... imagine, a region with 1,000 objects that used blobs. And, say, 2 blobs per object (pulling numbers out of thin air)
[13:23]	Rex Cronon:	but what if i am not interested to save the state of the scripts that in an linked set inventory, if i can use scripts to write to notecard, the script can save its onw state
[13:23]	Zero Linden:	and say 20k of data per blob
[13:23]	Zero Linden:	that's 20k x 1k x 2 = 40M
[13:23]	Hiro Market:	somewhere in the forum there's a reference to LL saying they'd open up a database for scripts to read/write data
[13:24]	Hiro Market:	seperatly to other mechanisms
[13:24]	Zero Linden:	and, since we store objects in XML -- you'd have to base 64 this when stored
[13:24]	Zha Ewry:	So, zero,suppose we assume that we use blobs, just to get objects (current set of SL native ones) into/outof the asset server
[13:24]	Zero Linden:	Since a typical region runs in 200M of RAM, and we try to keep it under 512M
[13:25]	Sifu Moraga thinks that the fact that my blobs are already XML doesn't help
[13:25]	Zha Ewry:	Which scopes things down a lot
[13:25]	Zero Linden:	you can see that this would start to put a strain on memory
[13:25]	Sifu Moraga:	But you could still have a local DB, though
[13:25]	Zha Ewry:	I'd love the more general solution, mind you, but I'm looking for ways for use to unload the storage issue (and the assembly issues) from SL and the scripters
[13:26]	Sifu Moraga:	not everything hast too be in memory, does it
[13:26]	Zero Linden:	Hiro - I don't know what forum post you're referring to -- but perhaps you are thinking about silo.php -- which is my script for storing arbitrary amounts of data on your own web server from LSL
[13:26]	Zero Linden:	?
[13:26]	Zha Ewry:	and let us (the developers who own the binary data) get it to the asset server as neatly as possible
[13:26]	Zha Ewry:	(and the converse, to get it out)
[13:27]	Zero Linden:	Zha- if your goal is to be able to add textures / sounds / notecards or even (gasp!) scripts to the asset system under LSL control.....
[13:27]	Hiro Market:	no, not silo, this is a reference to LL agreeing that not writing to notcards was an issue, and supplying a seperate database mechanism accessible by LSL
[13:27]	Zero Linden:	or similarly, to read that data out....
[13:27]	Hiro Market:	quite old, looking for it, caught my eye when I saw it
[13:27]	Zero Linden:	then perhaps we should talk about issuing capabilities to that information so you can just do it directly
[13:27]	Zha Ewry:	(and follow the DRM model, as we do it...)
[13:27]	Sifu Moraga:	Certainly that is not what I need blob transfer for
[13:28]	Zero Linden:	Oh, Hiro, don't know about there - there isn't a current plan internally that I know of
[13:28]	Zha Ewry:	Capabitlies, with the right strucfture, linked ot scripting, would get us most of the way.
[13:28]	Zha Ewry:	to
[13:28]	Sifu Moraga:	you think so, Zha?
[13:28]	Zero Linden:	Mind you - web server space that runs PHP is so cheep - seems like a much better solution to just have people store their own data in data stores they manage and pay for (and backup!)
[13:29]	Zha Ewry:	The question is mostly how to get the data from those servers into SL
[13:29]	Zero Linden:	Rather than the scaling issue of us managing a big writable store for everyeone...
[13:29]	Zero Linden:	Zha - this brings up my second question... which is - what do you want to do with the blobs
[13:29]	Sifu Moraga:	Unfortunatly, I'd rather have a standard-like solution like REST or SOAP (gad, ack)
[13:29]	Zha Ewry:	Now, to an extent, I'd be happy to bypass an asset server, but I'm stuck on how to do that such that it all works when the script moves across sim lines
[13:30]	Zha Ewry:	REST, not SOAP, please :-) and that's a personal not corporate preference :-)
[13:30]	Zero Linden:	and perhaps also notecards and sounds
[13:30]	Zero Linden:	and I'm sensing it is you want to import lots of textures into SL for autmated builds or catalogs or knowledge bases or some such
[13:30]	Zero Linden:	Ditto here, Zha --- personally, I don't like the taste of SOAP...
[13:30]	Sifu Moraga:	I know, I know, Zha, but I don't always decide....
[13:30]	Zha Ewry:	Well also to drive larger data driven scripts.
[13:31]	Zha Ewry:	We have lots of use cases where we don't (can't) do the compute in SL, nor do you want us to
[13:31]	Sifu Moraga:	So, what I;m doing with my notecards is to do some light processing on them and then sending them to an instrumented client
[13:31]	Zha Ewry:	But we need efficient ways of getting the data in, well beyond the 2048 bytes at a time solutions, and with less load on both the scripting workload
[13:31]	Zero Linden:	Right - but driving data driven scripts is easy - because since the scripts can't compute that much anyway, you just have the scripts request the data in chunks it can handle, which are going to be small
[13:32]	Zha Ewry:	and the http requests pounding the sims
[13:32]	Sifu Moraga:	And then, the instrumented client gives a notecard back and gives it to an object via the AV
[13:32]	Zero Linden:	Really? Surely you can process 2k worth of, say geometry instructions, in LSL in the 1/2 second it takes to fetch the next 2k
[13:33]	Zha Ewry:	If I want to texture, as I go, it gets worse, and I can drive a nice class five sim down to a time dialation of oh, .4 or ..3 with just geometry and scripts
[13:33]	Sifu Moraga:	I don't need to do much processing, except a bit of string replacement
[13:33]	Zha Ewry:	not even loading texutres. Just rezzing prims, and moving them into place in large numbers
[13:33]	Zha Ewry:	If I want to load textures, as I rez... its gets painful
[13:34]	Zero Linden:	Right - but I bet the load from the llHTTPRequest isn't really contributing to that problem
[13:34]	Sifu Moraga has seen what Zha is up to :-)
[13:34]	Zero Linden:	We tested doing several 100 llHTTPRequests per second in a sim with no noticable lag at all.
[13:35]	Zero Linden:	So, for driving scripts, I doubt getting the data in bigger chunks would be any better
[13:35]	Rex Cronon:	so zha, u want to build something off grid and upload those objects(or linked sets) into a sim?
[13:35]	Zero Linden:	Now, notecards and textures are two totally other problems
[13:35]	Hiro Market:	slightly tangental, but has support for procedural textures ever been considered?
[13:35]	Zha Ewry:	Hmm. Say, a 5500 prim molecular model? Yeah.
[13:35]	Sifu Moraga:	The problem I have is that I can't transfer the entire notecard in one piece, so I need to do about 4 transfers
[13:36]	Zha Ewry:	And then stich them together, and then run out of LSL memory
[13:36]	Zero Linden:	Righy - but doing the, I dunno, 100 2k data requests for the data for that molecule isn't nearly so much the load on the sim as rezzing and moving 'em
[13:36]	Sifu Moraga thinks the molecure is awsome
[13:36]	Zero Linden:	especially since I bet each of those has a script!
[13:36]	Zha Ewry:	One problem I see, is we end up with lots of scripts to deal with dataspace
[13:36]	Zha Ewry:	Not for long. We kill 'em as fast as we can.
[13:37]	Zha Ewry:	If I leave 5500 scripts listening, the sim is an unhappy place for 2 agents
[13:37]	Zero Linden:	none the less, the cost of starting a script far outweights the cost of doing one llHTTPRequest
[13:37]	Zero Linden:	Let's talk notecards -
[13:37]	Zero Linden:	Sifu - you seem to be wanting to do two things with them....
[13:37]	Zha Ewry:	Hmm. I'm not surprised. Scripts require lots of context
[13:37]	Zero Linden:	One is transmit coded data to a specially instrumented browser
[13:38]	Sifu Moraga nods
[13:38]	Vitis Obviate would use that also
[13:38]	Zero Linden:	You could, of course, use specially coded IM messages -- (what is that crypto product that works over AIM???)
[13:38]	Zha Ewry as well
[13:38]	Zero Linden:	but i imagine that is slow....
[13:39]	Zero Linden:	So - why not put the data via llHTTPRequest onto your server, and have the client retrieve it?
[13:39]	Sifu Moraga:	We thought of that, but still have to get it out to a web service at one point
[13:39]	Zero Linden:	granted, you have to take up the store of it
[13:39]	Zero Linden:	right - but the instrumented data is for the viewer, not the human, right?
[13:39]	Sifu Moraga:	that too
[13:39]	Zero Linden:	is it larger than 2k?
[13:39]	Sifu Moraga:	It also needs a bit or processing in-world
[13:39]	Sifu Moraga:	The data is for a cpu, its all XML, but unreadable
[13:40]	Sifu Moraga:	it is about 16kb in it's least cryptographicaaly secure form
[13:40]	Zha Ewry:	A fair bit of crypto/cert stuff ends up bigger than 2048...
[13:40]	Zero Linden:	We've had requests to have a version fo llHTTPRequest that is issued by the viewer, not the sim
[13:40]	Sifu Moraga:	easily
[13:40]	Zha Ewry:	Ah. There's a nice hard number
[13:41]	Sifu Moraga:	not the same problem, but still of interest for other stuff
[13:41]	Zero Linden:	so a script on the sim makes the request, the request is sent to the viewer, the viewer makes the call, and teh results piped back up to the
[13:41]	Zha Ewry:	Thus inside the client's firewall, and access to the local machine?
[13:41]	Zero Linden:	sim
[13:41]	Sifu Moraga:	yup
[13:41]	Zero Linden:	Right - the desire is to allow HUD objects that control things like MP3 players, and other, er, "add-ons"
[13:41]	Sifu Moraga:	more or less, though the firewall is incidental to what we are doing
[13:41]	Zha Ewry:	That helps although if its 2048, only a little, as you're still in the data stitching game
[13:42]	Zero Linden:	This strikes me as more of what you are after in this case, Sifu?
[13:42]	Sifu Moraga:	important is that we have two completely separate zone we need to access
[13:42]	Zero Linden:	Well, Zha, if the data has to go through LSL, while we can relax the size a bit (we intend to make it configuratble at some point)
[13:42]	Zero Linden:	it still won't be useful beyond, say 6k
[13:43]	Zha Ewry:	Right. Thus the desire to bypass LSL
[13:43]	Zero Linden:	since LSL execution space is going to be limited to 16k for quite some time
[13:43]	Sifu Moraga:	16 kb is the minimum
[13:43]	Zha Ewry:	I'm looking at how I can move bigger chunks without having them have to land in LSL at all
[13:43]	Zero Linden:	But - the only thing I think I hear that you'd entirely bypass LSL for is: Textures, and Notecards for users to read
[13:43]	Sifu Moraga:	It did occure that if we could just send the notecard directly from llHTTPRequest....
[13:43]	Zha Ewry:	Well, notecards for programs as well
[13:43]	Vitis Obviate:	yes
[13:43]	Sifu Moraga:	...that would bypass the LSL memory restrictions
[13:44]	Zero Linden:	Right - but where? If not a texture or a human readable notecard, then all other destinations in SL require LSL, yes?
[13:44]	Sifu Moraga:	I do think the use ofr notecards to be just wrong, somehow
[13:44]	Zha Ewry:	I'm happy to loop across a long notecard, one line at a time, never getting big chunks into the LSL data space
[13:44]	Vitis Obviate nods
[13:44]	Zero Linden:	Then why not read the data from your web server one line at a time? It is almost as fast, if not faster!
[13:44]	Sifu Moraga:	umm, you'l be happy until you have tried it like me
[13:45]	Zha Ewry:	I'm muchg less happoy trying to coordinate that across http gets with all the logic to deal with dropped /oiur of order stuff
[13:45]	Sifu Moraga:	I get some delay that the users don't like
[13:45]	Sifu Moraga:	yes, that is worse
[13:45]	Zero Linden:	Indeed, the notary reads notecards one line at a time (needs to for hashing) and it is a bear
[13:45]	Zha Ewry:	I also see about 50% of my code space go into the parse/manage packet order problem
[13:46]	Zero Linden:	Really? Why not just issue your HTTP requests serially, like you'd do for notecards?
[13:46]	Sifu Moraga:	Also, I can't get llHTTPrequest to add chunking headers
[13:46]	Zha Ewry:	I understand the 16K problem, so I'm looking for reaosnale ways to bypass it
[13:46]	Zha Ewry:	I can issue them serially, but I have to have chunking/retry logic and I do end up exercising ti
[13:46]	Zha Ewry:	it
[13:47]	Zero Linden:	By the way - I'm not trying to be resistant - just trying to really get at what the user needs are here -- alas, with our highly constrained system, and our opaque implementation, it is hard to know what the crux of a user problem is
[13:47]	Sifu Moraga totally understands
[13:47]	Zha Ewry:	Yes, I get that And having the discusssion is the right way to do it
[13:47]	Zha Ewry:	I'm totally happy witrh this process, at the moemnt
[13:48]	Zero Linden:	ah- I think I'm now seeing the bigger issue - here
[13:48]	Zha Ewry:	Point a number of people at the problem, and get to a good technical answer works for me
[13:48]	Zero Linden:	I'm wondering then if instead we supported byte-ranges,
[13:48]	Sifu Moraga:	If I was travelling to SF any time soon, I'd love to have a RL discussion of it
[13:48]	Sifu Moraga:	(unfrotunatly, I'm not)
[13:48]	Zero Linden:	and since our requests are squid cached
[13:48]	Zero Linden:	if that would work - because squid requests the whole thing when you do a byte range request
[13:49]	Zero Linden:	so once the frist range worked
[13:49]	Zero Linden:	you'd be getting the rest out of the cache
[13:49]	Zha Ewry:	Oh, allow us to load a bigger chunk into the squid, and then grab it 2048 at a time?
[13:49]	Sifu Moraga thinks
[13:49]	Zero Linden:	Exactly- if everyone played right by the headers and all....
[13:50]	Sifu Moraga doesn't get it
[13:50]	Zero Linden:	If you do a GET to say http://example.com/foo/bar
[13:50]	Zero Linden:	but include a byte range header asking for bytes 0-2047
[13:50]	Zha Ewry willing to be a very obedient header wreiter
[13:50]	Zero Linden:	Squid cache will instead ask for the whole thing
[13:50]	Zero Linden:	and cache the whole resource at that URL
[13:50]	Zero Linden:	and deliver only the requested bytes
[13:50]	Zero Linden:	when you then make a second request to the same URL
[13:51]	Zero Linden:	but with byte range 2048-4095
[13:51]	Zha Ewry:	with the byterange...
[13:51]	Zha Ewry:	Yes..
[13:51]	Zero Linden:	squid just answers out of the cache
[13:51]	Vitis Obviate will use whatever incontonation is required
[13:51]	Zha Ewry:	How big a chunk could the squid handle?
[13:51]	Zero Linden:	Now, mind you, it is all REST and stateless... so
[13:51]	Zha Ewry likes REST and stateless...
[13:51]	Zero Linden:	in theory, you could have squid drop the resource in the middle and have to refetch
[13:51]	Vitis Obviate:	fine with me
[13:51]	Sifu Moraga thinks REST is good
[13:51]	Zha Ewry:	Yes, just delay on random fetches if it does
[13:52]	Zero Linden:	Squid? Oh, I don't know what our maximum cached object size is set to....
[13:52]	Zha Ewry:	as long as the URL is idempotent, we're ok
[13:52]	Zha Ewry smiles
[13:52]	Zero Linden:	right now it is probably pretty large... 1M or so?
[13:52]	Zero Linden:	Exactly, Zha
[13:52]	Zha Ewry:	I can deal with that :-)
[13:52]	Zha Ewry:	Doesn't help with textures or sounds, but... it would help a lot.
[13:52]	Zha Ewry:	Be harder to do in the other direction, I'd imagine
[13:53]	Zero Linden:	Yes - but there there is the much more natural solution - just let you texture an object with a URL to your own image on your own server...
[13:53]	Zero Linden:	Not that we are doing that right now....
[13:53]	Zha Ewry:	Yes.
[13:53]	Zero Linden:	We do have to be careful about opening the flood gates to textures
[13:53]	Hiro Market:	like the sound of that
[13:54]	Zha Ewry:	That'd be fine, within reason. How exactly we get the proggramitrc control is interesting, but I can see ways.
[13:54]	Zha Ewry:	Yes, I'm wiling to hear lots of stories about throttle on textures
[13:54]	Zero Linden:	Obviously if everyone just uploaded a texture for every surface they needed, under LSL command... we'd see things like
[13:54]	Hiro Market:	from my perspective one of the biggest restrictions on LSL is not being able to programatically manipulate textures
[13:54]	Zero Linden:	billboards that uploaded new textures every 15 seconds
[13:54]	Rex Cronon:	it would be ok to me if instead of html i can use svg
[13:54]	Hiro Market:	at pixel level
[13:54]	Zero Linden:	which would be cool from the SL experience point of view
[13:54]	Zha Ewry:	Yes... throttleing is an issue, of course.
[13:54]	Zero Linden:	but would really kill the asset server
[13:54]	Zha Ewry:	Althoug.. if you can have "transient" textures
[13:55]	Sifu Moraga:	It does sound like you will need the concept of transient blobs stored by the sims
[13:55]	Zha Ewry:	locally cached, I can come up with a story that only pounds the sim
[13:55]	Zha Ewry:	And not even that bad.
[13:55]	Zero Linden:	Hiro - you aren't likely to see things like paramatic textures or pixel level texture control from LSL
[13:55]	Zha Ewry:	The sim has to fetch/cache the tyextures today
[13:55]	Zero Linden:	These are memory and process intensive operations that the sim doesn't have the resoruces to do
[13:55]	Zha Ewry:	Nor should it
[13:55]	Zero Linden:	what is more likely, what scales much better, is
[13:55]	Zha Ewry:	Keep as much rendering on the client as possible
[13:55]	Hiro Market:	again I wonder about procedural textures on the client with shader code on server
[13:56]	Zha Ewry nods at Hiro
[13:56]	Zero Linden:	do the pixel level processing on your own computer or server - and then have a way to put that texture on an object
[13:56]	Zero Linden:	The servers, the sims, have no graphics hardware at all... so no OpenGL going on there
[13:56]	Zha Ewry:	I think mosgt of us who have loooked at the scale issues want a smuch rendering as possible on the client
[13:56]	Zha Ewry:	I don't want the SIMs even thinking about rendering
[13:56]	Hiro Market:	don't need it, just the shader code on server, rendered on client
[13:57]	Zero Linden:	don't expect the sims to be doing graphic manipulation or rendering (which is a hint, by the way, as to why the map is such a pain point for us!)
[13:57]	Zha Ewry:	Among other horrors, you end up with the sim needing to know things like the resolutoin of every client they are talking to
[13:57]	Zero Linden:	Ah - but Hiro, can you imagine what it would be like if an object could down load arbitrary shader code to your viewer?!?!?
[13:57]	Hiro Market:	but procedural shader code is simply code, no rendering on server required at all
[13:57]	Zero Linden:	Talk about griefing!
[13:58]	Hiro Market:	hmm, point taken, but the advantages must be worth exploring surerly?
[13:58]	Zha Ewry:	He. Just because sooner or later we'd have all the pron spam in the shader :-)
[13:58]	Zero Linden:	Alas, OpenGL doesn't have virtualization or sandboxing facilities to make that reasonable
[13:58]	Zero Linden:	Nor does anyone have shader verifiers as far as I know....
[13:58]	Zero Linden:	But - one could imagine in
[13:58]	Zero Linden:	the future
[13:58]	Sifu Moraga thinks there might be a case for somre rendering on the server, but it would probably need a different architecture
[13:59]	Hiro Market:	3dlabs have one
[13:59]	Zha Ewry shudders at what you could get the shader to do.
[13:59]	Hiro Market:	a verifier that is
[13:59]	Zero Linden:	private sims that said "If you come here, I will use spiffy special purpose shaders.... allow?"
[13:59]	Rex Cronon:	talking about griefing, what exactly does the physics engine do to attachements, when the one that wears them is blitzed?
[13:59]	Zha Ewry:	Hm. That'd be interesting
[13:59]	Zha Ewry:	In general, the question of private sim behavioir is interesting
[13:59]	Zero Linden:	Hiro - curious - good to know - though again I wonder if it worries about hostile environments or just makeing sure things won't crash...
[14:00]	Sifu Moraga:	My cranial CPU is shutting down, and my Powerbook is out of juice, so I'm off early
[14:00]	Sifu Moraga:	cu all
[14:00]	Zero Linden:	Yes, it is.... short term, once we start letting estate owners control upgrade times.... we are going to have to deal with
[14:01]	Zero Linden:	viewers and regions with different feature sets....
[14:01]	Zha Ewry:	Yes
[14:01]	Zero Linden:	Well, Sifu - actually it is 2pm so I'm signing off soon too
[14:01]	Zero Linden:	Shorter term -
[14:01]	Zha Ewry:	we talked about tadeoffs, between number of scirpts and data spaces and such
[14:01]	Zha Ewry:	last week.
[14:01]	Zha Ewry:	So lots of things I'd love to be able to contrrol on the sim :-)
[14:02]	Zero Linden:	one could easily imagine custome viewers that have special shaders in 'em and then some way for objects
[14:02]	Zero Linden:	to invoke that shader behavior if running on viewer that has 'em
[14:02]	Zha Ewry:	Wow. This was incredbly useful Zero. Hope it was for you. I'll try and update my blob comments a bit. and think about some of your comments
[14:02]	Zero Linden:	Zha - yes - though realize, like all server tuning, the more parameters you have, the better performance you can achieve, but the more compicated it is for people to manage it
[14:03]	Zha Ewry:	Hey I race saliboats. More strings, more fast. or more slow.
[14:03]	Zha Ewry:	so, yes.
[14:03]	Zero Linden:	and - one has to realize that you can only do so much, even with so many knobs
[14:03]	Zero Linden:	(thinks of tuning squid, or apache, or mysql....)
[14:03]	Zha Ewry:	Yep. 1 cpu, 512M of memory, etc.
[14:03]	Zha Ewry:	But, there are cases where we can play those off well
[14:04]	Zero Linden:	It is great - I'm very happy with my office hours experiences - and have been talking up how good they are inside of LInden
[14:04]	Zha Ewry:	Thanks again Zero, as always. Really focused discussion today
[14:04]	Zero Linden:	Thanks all for coming
[14:04]	Zero Linden:	See you next time.
[14:04]	Kooky Jetaime:	Thank you Zero
[14:04]	Vitis Obviate:	very valuable info - ty
[14:04]	Drewan Keats:	Thanks Zero.
[14:04]	Hiro Market:	ty zero, aoppreciated
[14:04]	Zha Ewry:	Thanks everyone, actually, very good discussion today