User:Zero Linden/Office Hours/2007 Mar 20

Transcript of Zero Linden's office hours:

[13:03]	Frank Bogomil:	later
[13:03]	Sifu Moraga:	Hi Zha
[13:03]	Tleiades Hax:	Mono doesn't really support runtime security
[13:03]	Zha Ewry:	Hello
[13:03]	Tleiades Hax:	hi Zha
[13:03]	Zha Ewry:	all
[13:03]	Tleiades Hax:	hi Sifu
[13:04]	Zha Ewry:	Howdy Zero
[13:04]	Tleiades Hax:	hi Zero
[13:04]	Sifu Moraga:	Hi Tleides
[13:04]	Frank Bogomil:	yes, or small enough arenas, but it is open source
[13:04]	Zero Linden:	hello hello hello
[13:04]	Frank Bogomil:	hi zero
[13:04]	Rex Cronon:	hi everybody
[13:04]	Sifu Moraga:	errr, Zha.....
[13:04]	Zero Linden:	welcome to any SLDev folks
[13:04]	Zha Ewry:	Ythe AO?
[13:05]	Tleiades Hax:	yes, AO's will do that to you
[13:05]	Sifu Moraga:	ssss
[13:06]	Frank Bogomil:	this is my first time, what is the format?
[13:06]	Zero Linden:	I'm gonna wait a few more minutes, as login is a little slow
[13:06]	Zero Linden:	the format is free wheeling
[13:06]	Tleiades Hax:	k
[13:07]	Zero Linden:	though I sometimes call a halt to a topic so we can fit some others in
[13:07]	Sifu Moraga:	I'm still filling my cache
[13:07]	Frank Bogomil:	I have two topics: standardization/documentation of the protocol and moving computation to the viewer
[13:08]	Sifu Moraga:	While we are waiting, Zero, is there a good point of contact for security specific stuff?
[13:08]	Zero Linden:	security@lindenlab.com
[13:08]	Sifu Moraga:	I meant more for discussion
[13:08]	Zero Linden:	it gets very closely read by engineers
[13:08]	Sifu Moraga:	Oh, ok
[13:08]	Zero Linden:	oh - well, none as of yet - but
[13:09]	Zero Linden:	perhaps you could ask on SLDev -- and maybe it would help prod some of the other engineers into holding office hours too!
[13:09]	Sifu Moraga:	good idea.
[13:09]	Rex Cronon:	at least once a week
[13:09]	Zero Linden:	:-)
[13:09]	Zero Linden:	Okay - let's start
[13:10]	Zero Linden:	as always, but also for the newcomers
[13:10]	Sifu Moraga:	Security is my thing, but I don't want to email into a black hole
[13:10]	Sifu Moraga:	k
[13:10]	Zero Linden:	the transcript will be posted on the wiki
[13:10]	Zero Linden:	oh - and a thanks to Dr. Scofield for the transcript formatting perl script
[13:10]	Zero Linden:	I'll be applying it to the others soon
[13:11]	Sifu Moraga:	I'll relay the tx
[13:11]	Zero Linden:	So - just a quick show of hands... how many here read SLDev regularly?
[13:11]	Tleiades Hax:	the mailing list?
[13:11]	Zha Ewry avoids the IP containation, at the moment
[13:12]	Zero Linden:	yes
[13:12]	Zha Ewry:	contamination
[13:12]	Tree Kyomoon:	no
[13:12]	Frank Bogomil:	i do now
[13:12]	Tleiades Hax raises his hand
[13:12]	Frank Bogomil raises hand
[13:12]	Sifu Moraga:	same problem as Zha, though I usually don't take it as seriously
[13:12]	Hiro Market:	will now
[13:12]	Rex Cronon:	what is the link for that?
[13:12]	Zero Linden:	okay - well, last week I responed to some discussion there about the message system, and pointed those folks at our transcript from the day I showed all the pictures
[13:13]	Rex Cronon:	oh the one from your page zero?
[13:13]	Zero Linden:	https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev
[13:13]	Zero Linden:	yes, the message system slides
[13:13]	Zero Linden:	and there was some discussion
[13:13]	Tleiades Hax:	I read the transcript and studied the slides
[13:13]	Zero Linden:	a really valid point was made about documentation and the protocol
[13:13]	Tleiades Hax:	and they made a little worried
[13:13]	Zero Linden:	I'd like to address that here a bit
[13:14]	Tleiades Hax:	exactly .. documentation
[13:14]	Zero Linden:	The message template, for all it's bad points, is good in that it is a single file that documents all the messages in the system
[13:14]	Zero Linden:	only, of course, it doesn't as it only captures messages sent via UDP
[13:15]	Zero Linden:	it misses things like internal REST services, XML-RPC bits, the DB schema, etc...
[13:15]	Zero Linden:	not that all of those things go to the viewer (though some do!)
[13:15]	Frank Bogomil:	ImprovedTerseObjectUpdate ObjectData Data
[13:16]	Zero Linden:	Right, and then there are the very carefully hand backed binary blobs (and some not so carefully packed ones)
[13:16]	Zero Linden:	these of course are opaque
[13:16]	Zero Linden:	wihtout the code to decode 'em
[13:16]	Phil Deakins:	hi all
[13:16]	Zha Ewry nods. Very opaque
[13:16]	Rex Cronon:	hi
[13:17]	Zero Linden:	well... you do have the code... which is frankly as much as any of us in LL have too!
[13:17]	Tleiades Hax:	Hi Phil ... Jade
[13:17]	Jade Angkarn:	Hi
[13:17]	Zero Linden:	When we move to LLSD based messaging, things change
[13:17]	Zero Linden:	mostly because things are, intentionally, much more flexible
[13:18]	Zero Linden:	so the question becomes how to document the semantics when there is nothing in the code that requires explicit documentation
[13:18]	Zero Linden:	We think the answer lies in making possible to author the doc right in the code....
[13:19]	Sifu Moraga:	Semantics, the final unsolved frontier...
[13:19]	Zero Linden:	otherwise programmers are unlikely to keep things in sync
[13:19]	Zero Linden:	There is a very early stab at this now in the code
[13:19]	Zha Ewry nods
[13:19]	Tleiades Hax:	in that case I would sugges some variant of Java doc
[13:19]	Zero Linden:	if you look at LLHTTPNode, you'll see that it has a description() method
[13:19]	Frank Bogomil:	alternatively, you can have a schema definition which is compiled into an API and enforce it that way
[13:19]	Rex Cronon:	yes
[13:19]	Zha Ewry rolls her eyes @ schema
[13:20]	Sifu Moraga likes the javadoc approach but worries about non-english speakers
[13:20]	Zero Linden:	No - we can't enforce schemas - the point of LLSD is to make all messaging be forward and backward compatible
[13:20]	Frank Bogomil:	documentation/comments in code are notoriously falling out of sync
[13:20]	Zero Linden:	it is expected that people will send you messages that you can only half parse, but still use
[13:20]	Tleiades Hax:	if you write code, you speak english :-)
[13:20]	Zero Linden:	Right - so, no javadoc, no comments
[13:20]	Sifu Moraga:	no, I speak Java or Perl or whatever
[13:20]	Zha Ewry:	Schema is a straight jacket for versioning
[13:20]	Zero Linden:	instead, you override a function that returns the description
[13:20]	Frank Bogomil:	the API can include a superset of prior APIs with syntactic distinguishers
[13:21]	Sifu Moraga remembers a language by Donald Knuth that was all documentation ...
[13:21]	Tree Kyomoon:	mmm overhead
[13:21]	Zero Linden:	then there is a service on the process that returns the aggragate, machine readable info
[13:21]	Frank Bogomil:	that way your people will know when they are using old APIs
[13:21]	Zero Linden:	we already has this
[13:21]	Zero Linden:	*have
[13:22]	Zero Linden:	see llmessage/lliohttpserver.cpp -- me thinks
[13:22]	Zero Linden:	llsdhttpserver.cpp
[13:22]	Tleiades Hax:	the problem is getting the broad picuture
[13:23]	Zero Linden:	the URL /web/server/api will return a full list of all messages a server undertsands
[13:23]	Zero Linden:	This actually works today in the simulator and other backend servers
[13:23]	Zero Linden:	then /web/server/api/<...path here...>
[13:23]	Rex Cronon:	why can't u just ask the server if it understand a specific version?
[13:23]	Zero Linden:	returns the documentation for that message
[13:24]	Zha Ewry:	Version is coarse grained
[13:24]	Zero Linden:	versions imply a linear evolution, which probably isn't realistic long term
[13:24]	Zero Linden:	while there is a main trunk -
[13:24]	Zha Ewry:	this is fine grained
[13:24]	Zero Linden:	there will always be off shoots
[13:24]	Zha Ewry nods. What Zero is saying... :-)
[13:25]	Zero Linden:	besides, version numbers lead programmers to offer services that are all or nothing, and not gnerally forward compatible
[13:25]	Frank Bogomil:	the solution you are describing requires the client to conform to the server, so the client has one "schema" and the server another, and you have to modify the messages to be compatible
[13:25]	Frank Bogomil:	in general, that is not an easy problem
[13:25]	Zero Linden:	no, the server is always free to tell the client "huh?"
[13:25]	Zero Linden:	but yes,
[13:25]	Zero Linden:	the client has to be prepared, if it wants to use some feature, to get "huh?"
[13:25]	Tleiades Hax:	will there be some sort of fall back strategy?
[13:25]	Zero Linden:	and fall back or abort
[13:26]	Zero Linden:	depends on the message and the semantics -- again, why version numbers don't usually capture the different scenarios -- they are very individual
[13:26]	Frank Bogomil:	but with version nmbers you can provide converters which are driven by higher level semantics
[13:27]	Zero Linden:	for example, posting a parcel for sale, may or may not support new advanced features, "bidding" or "auction" or "minimum price" or "mortgague"
[13:27]	Sifu Moraga:	hmmm. I should pose the question to some of our hard core WS guys in the lab...
[13:27]	Zha Ewry:	if, and only if, you can tie changes to version numbers
[13:27]	Tleiades Hax:	true, I like the flexible approach, but I worry about documenting semantics, and performance implications for the individual options
[13:27]	Frank Bogomil:	if you leave it up to some piece of code, it has to decide what to do about missing, added, reformated messages
[13:27]	Zha Ewry:	This is the old WSDL discussion in new clothes
[13:27]	Frank Bogomil:	messagees which are split, etc. it is a hard problem
[13:27]	Tleiades Hax:	true
[13:27]	Zero Linden:	it is up to people extending the protocol to support what happens when old viewers post, or newer viewer?
[13:28]	Zha Ewry:	Do we version on messages, or ports
[13:28]	Zero Linden:	and newer viewers need to be prepared to get a response that says "uh, I did a normal sale..."
[13:28]	Sifu Moraga:	yep, I'm afraid they will tell me to go use SOAP and all the problems will go away. har har
[13:28]	Zha Ewry:	Services or single bits of schema
[13:28]	Zha Ewry:	This is somewhat more REST friendly
[13:28]	Zero Linden:	yes - we are very much more REST than WSDL
[13:29]	Tleiades Hax:	sound as if the network protocol will consume a lot of bandwith and CPU power
[13:29]	Zero Linden:	I don't think the performance will an issue at all -- we aren't checking the schema on recption or send
[13:29]	Zero Linden:	and the extra cost of making the transmission format be self-describing is not turning out to be very much
[13:29]	Zha Ewry:	What is you base represntation insde http? I'
[13:30]	Zha Ewry:	I'm betting it isn't a tree of XML ;-)
[13:30]	Tleiades Hax:	what kind of time frame are we talking about?
[13:30]	Zha Ewry:	Which should keep the performnce fom geting horrible, if you don't do that and don't validate
[13:30]	Tree Kyomoon:	that would be nice zha
[13:30]	Zha Ewry:	Not ifyou have to validate
[13:30]	Zha Ewry:	Lifetime supply of angle brackets in a single message
[13:31]	Zero Linden:	wow - there is a concert in the next parcel over... that is that eerie sound!
[13:31]	Zero Linden:	LLSD can be serialized into either XML or a compact binary format
[13:31]	Frank Bogomil:	so who is responsible for doing the protocol conversion, client or server?
[13:31]	Zero Linden:	we don't validate -
[13:31]	Zha Ewry:	Compact Binary, over here, please :-)
[13:31]	Sifu Moraga:	!
[13:32]	Frank Bogomil:	but semantically
[13:32]	Zero Linden:	the scheme for LLSD in XML isn't very helpful anyway -- the parse just validates as it goes
[13:32]	Sifu Moraga:	ah, ok then
[13:32]	Zero Linden:	actually - I'm not sure if the compact binary will be a big win over just gzipping the HTTP stream of XML
[13:32]	Zha Ewry nods. A lot of people validate, for very little gain, as they end up parsing like that
[13:33]	Zero Linden:	but, we'll measure it and see
[13:33]	Tleiades Hax:	ok, but how do you plan to document the gramar
[13:33]	Zero Linden:	right - we are parsing anyway - so no need to validate - the conversion into C++ LLSD will catch the element errors
[13:33]	Zero Linden:	and expat will catch the XML format errors
[13:33]	Zero Linden reading scroll back
[13:34]	Zha Ewry:	Zero is doing one of Zha's fsavorite things. Code, then measure. Rather than guess and be wrong.
[13:34]	Frank Bogomil:	but who will catch changing semantics?
[13:34]	Tleiades Hax:	which is fine for the viewer and server, but the procol will become a rendevous for interoperability
[13:34]	Zero Linden:	Time frame: We will be rolling the full support for messages in LLSD over TCP based transports into release in two weeks
[13:34]	Sifu Moraga:	is there really an answer to the semantics qustion?
[13:34]	Zero Linden:	only all the LLSD/TCP messages will be turned off - they will all still go UDP
[13:34]	Tree Kyomoon:	wow two weeks!
[13:34]	Frank Bogomil:	there are a number of answers, version numbers + custom conversion is one
[13:35]	Zero Linden:	then about a release after that - new messages, and updated messages will all start going LLSD/TCP
[13:35]	Tleiades Hax scraps about 5kloc code
[13:35]	Frank Bogomil:	this is how shared object libraries are handled... major minor version, one incompatbile and one compatible
[13:35]	Zha Ewry:	Tleades Hax, seems to me, if you do interop, over it, the same parsing obtains. You might have to do parser to oher
[13:35]	Sifu Moraga:	Silly side question, have you considered replacing UDP with SCTP?
[13:35]	Zero Linden:	Protocol conversion: as shown in the slides we do alot of automatic conversion for existing messages - both on the wire side (to go UDP or LLSD/TCP)
[13:36]	Zha Ewry:	object streams
[13:36]	Zha Ewry:	but the same approach would work
[13:36]	Zero Linden:	and on the C++ API side (to get the data via the old Binary API or via LLSD)
[13:36]	Zero Linden:	for new messages, we will be getting developers in LL to start using the new stuff ASAP
[13:36]	Tree Kyomoon:	lookin forward to it!
[13:36]	Frank Bogomil:	so backward compatibility is embedded in the code handling each function?
[13:37]	Zero Linden:	Grammar: It is mostly a matter of documenting which key/value pairs each message takes
[13:37]	Frank Bogomil:	does the desc() handle that?
[13:37]	Zero Linden:	Again - we will try to do this by getting the programmer to code it -- which should be no worse than we are now...
[13:39]	Zero Linden:	Yes - when you decided to extend a message, you must write your handler to test for the existance of the extension
[13:39]	Zero Linden:	LLSD makes this easy: body.has('bob')
[13:39]	Frank Bogomil:	and those choices are contained in the desc()
[13:39]	Zero Linden:	or in most cases you can just grab the value and check for empty:
[13:39]	nokithecat Writer:	This sim area realy messes up Avatars, I was fine untill I came here!!!
[13:39]	Zero Linden:	LLUUID thing_id = body['thing-id']
[13:39]	Tleiades Hax:	hmm, and if the client extends the protocol?
[13:39]	Frank Bogomil:	and are automatically extracted or manually entered?
[13:39]	Zero Linden:	it'll be NULL if not present
[13:39]	Zero Linden:	it will be ignored --- so, if
[13:40]	Zero Linden:	the client needs to depend on the server understanding it
[13:40]	Zero Linden:	then you must build confirmation into your extension
[13:40]	Frank Bogomil:	seems like you would need to trace the code to extract the complete accepted protocol
[13:40]	Tleiades Hax:	which is fine, if you never plan to implement ctc
[13:40]	Zero Linden:	since most of the messages now are built this way anway - (remember, it is UDP) this is easy
[13:40]	Zero Linden:	Frank - you would
[13:41]	Zero Linden:	but mostly messages have a set of needed values
[13:41]	Zero Linden:	and some optional ones
[13:41]	Tree Kyomoon:	unrelated..is there a timeline in splitting the avatar server off the simservers yet?
[13:41]	Zero Linden:	and extensions are generally additional optional
[13:41]	Zero Linden:	so - think like unix command line
[13:41]	Zero Linden:	you need to trace teh code to know for sure the accepted grammer
[13:41]	Zero Linden:	but usually 'cmd -h' tells you all you need to know
[13:41]	Zero Linden:	because there is a convention to usage
[13:41]	Frank Bogomil:	I am concerend with making interoperable products and it seems like this approach is going to make that very difficult
[13:42]	Tleiades Hax:	but that still won't give you the big picture
[13:42]	Zero Linden:	We consider making interoperable products with flickr
[13:42]	Zero Linden:	It is not the same as making them with, say, IPSEC
[13:43]	Zero Linden:	In the flickr case, you have a transport (in the generic sense) that supports a fair degree of slop
[13:43]	Frank Bogomil:	HTTP parsing was hardest not because of what was accepted by one person but because you had to accept everytihng which was accepted by anyone
[13:43]	Zero Linden:	and so, rather than define hard coded APIs, it is sufficent for them to put up a few web pages
[13:43]	Frank Bogomil:	which means that any compatible server would have to understand all the weird paths in the LL code
[13:43]	Frank Bogomil:	so this is probably fine for clients, but not for servers or proxies
[13:44]	Zha Ewry:	Frank, I think thep oint of concern, is the amount of forking on the message formats
[13:44]	Zha Ewry:	If its high, and you can't transpatently pass it along, then its paintful
[13:44]	Zero Linden:	I see, at some point, the protocols being more agreed upon and more stable
[13:44]	Frank Bogomil:	yes, but without preventing progress :)
[13:44]	Zero Linden:	There is generally, little message evolution
[13:45]	Sifu Moraga:	That might be a dangerous assumption
[13:45]	Zero Linden:	And becuase the format is self describing, proxies will have a very good time of it
[13:45]	Zha Ewry:	if its low, or you can pass along parts you don't understand, then proxy is easy, and the servers arent too bad
[13:45]	Zero Linden:	The key is more designing the messages to be more self contained, and resillient
[13:45]	Frank Bogomil:	servers are bad because they might depend on any of the paths in the LL server which aren't docuemnted
[13:45]	Zha Ewry:	Servers, in general, are going to have a hard time, as peers, if they don't have very stable protocols
[13:46]	Frank Bogomil:	that is clients might depend...
[13:46]	Zero Linden:	Well - think of HTTP - the substrate, the transport of HTTP is well defined -- that is what we're building at this stage with LLSD and TCP based transports
[13:46]	Zero Linden:	The next level up the stack, simulator access, will come in time to be a more stable protocol
[13:47]	Zero Linden:	but, like things built in HTTP, it will have to be one of extension and possibility
[13:47]	Frank Bogomil:	HTTP proxies (which I built in a former life) had to be bug compatible with many servers, and that was hard
[13:47]	Sifu Moraga:	Then you might need a way of deprecating old message formats
[13:48]	Frank Bogomil:	or at least documenting the entire range of accepted messages
[13:48]	Zero Linden:	Frank - I don't know of ANY protocol, no matter how many RFCs exist, that doesn't have that probelm!
[13:48]	Frank Bogomil:	true true
[13:48]	Sifu Moraga:	yep
[13:48]	Zero Linden:	DNS is well spec'd... but there is devil in the details of how some DNS servers operate
[13:48]	Tleiades Hax:	:_)
[13:48]	Frank Bogomil:	the question is, how hard is it, and whether accidental or by design
[13:48]	Frank Bogomil:	this design permits great underdocuemnted flexibility in the messages accepted at the server
[13:49]	Zero Linden:	There is no denying that SL's current protocol was designed and built on an as needed basis
[13:49]	Tleiades Hax:	well, as long as it doesn't have some obscure rule for ordering parameters inside a message :)
[13:49]	Zero Linden:	That said, some fundimental choices were very good and will keep the tenor of the system coherent: like
[13:50]	Zero Linden:	making sure that messages were requests - and would require response messages if ack was needed
[13:50]	Zero Linden:	As for the lower level -- as I've said, that is being addressed by the chane to LLSD/TCP
[13:50]	Frank Bogomil:	I would just like to see the entire accepted (by server) protocol documented somewhere
[13:50]	Zero Linden:	at least from that point forward, you'll be able to inspect things easily
[13:51]	Zero Linden:	Frank- so would I
[13:51]	Tleiades Hax:	will everything go to TCP, including avatar movement?
[13:51]	Zero Linden:	No, a few things will probably stay UDP forever -- though we might make TCP only an option for those environments that need it
[13:51]	Rex Cronon:	llsd=lindens lab secure datagram?
[13:52]	Zero Linden:	we've managed to put everything through TCP so far except those messages that used aspects of the lowlevel UDP transport
[13:52]	Zero Linden:	for throttling -- since we'd have to rebuild that for TCP -- for now that isn't worth it
[13:52]	Zero Linden:	okay - we've
[13:52]	Zero Linden:	spent a long time on this
[13:52]	Zero Linden:	which is fine - but are there some other things anyone wants to touch on?
[13:52]	Tree Kyomoon:	any progress on avatar/sim splitting servers?
[13:53]	Zero Linden:	I can speak to some security questions
[13:53]	Zero Linden:	Ah - that is still in the design and planning stage --
[13:53]	Zero Linden:	I'll be working out what is the first phase of that to do in the next two weeks as it will be part of my Q2 goals
[13:53]	Zha Ewry:	Also, did you eidea of usding the squid and byterange stuff. to get at bigger inbound hhtp respsonses anywhere beyond our chat?
[13:54]	Zha Ewry:	Gah. Did your idea of squid and byternage get beyond our chats? (take 2)
[13:54]	Zero Linden:	not yet - but I'm going to put in a feature request -- I'm pretty sure the squid side is all ready to do that
[13:54]	Zero Linden:	the only missing part is the byterange parameters
[13:54]	Tree Kyomoon:	http images on a prim?
[13:55]	Zha Ewry:	Alas, I've yet to think up an equally clever outbound scheme... But that would be cool. Any idea how long it might take to get from eature request to code?
[13:55]	Zero Linden:	I'm trying to get someone internally to take on that discussion
[13:55]	Rex Cronon:	svg instead of html on a prim?
[13:55]	Zero Linden:	I'd like to get it out in the open on the wiki - not just buried on my office hours page
[13:55]	Sifu Moraga:	I think what I'll do with the security Q's I have is to look through the forums and see what already has been discussed before posing them to you.
[13:55]	Zero Linden:	and then we can get some internal motion on it
[13:55]	Zero Linden:	there are folks that are interested - but I'd say they'd like to be guided by what is needed -
[13:56]	Tree Kyomoon:	flash progress?
[13:56]	Zero Linden:	none that I've heard of...
[13:56]	Frank Bogomil:	http://foo.com/bar.jpg textures?
[13:56]	Tree Kyomoon:	real arrays in LSL?
[13:57]	Tleiades Hax:	write your own compiler :-)
[13:57]	Sifu Moraga thinks that is a lot to discuss in 3 minutes
[13:57]	Zha Ewry is amazed Zero isn't hiding under a invisiprm by now
[13:57]	Zero Linden 's head is spinning
[13:57]	Frank Bogomil:	teatime ? :)
[13:57]	Tree Kyomoon:	discussion compression
[13:57]	Sifu Moraga:	there is always thursday
[13:57]	Hiro Market tosses in multiple textures on a prim too
[13:57]	Zha Ewry:	Yes, thursday.
[13:58]	Tleiades Hax:	will we have some sort of preview of the new protocol
[13:58]	Zero Linden:	doubt multple textures on a prim face is likely
[13:58]	Tree Kyomoon:	did you discuss what heppened to Zero last time?
[13:58]	Hiro Market:	on a face that is
[13:58]	Zha Ewry:	He posted in the wiki
[13:58]	Tree Kyomoon:	cool
[13:58]	Tree Kyomoon:	thx
[13:58]	Zha Ewry:	A nice apology
[13:58]	Rex Cronon:	maybe there should be list of discussion topics at begining of your ofice hourse zero?
[13:58]	Zero Linden:	Sorry - I was at SXSW on Tuesday -
[13:58]	Tleiades Hax:	I only saw some diagrams
[13:58]	Zero Linden:	and on Thrusday - I was sleeping - recovering from SXSW - which is mostly a lot of late night parties
[13:58]	Tleiades Hax:	no samples of messages or any thing
[13:58]	Sifu Moraga:	lucky you
[13:59]	Zero Linden:	For now - the messages are no different than those in the message template
[13:59]	Sifu Moraga:	:-)
[13:59]	Tree Kyomoon:	lol ah to be a youngster again...
[13:59]	Sifu Moraga:	Zurich is so boring....
[13:59]	Zero Linden:	just packed in LLSD, rather than binary
[13:59]	Hiro Market:	i'm kinda curious how SL will upgrade graphically without features like multiple texturing, shaders and the like
[13:59]	Zero Linden:	so body['BlcokName']['VariableName'] = value
[13:59]	Tleiades Hax:	ok, so same message semantics
[13:59]	Tree Kyomoon:	antialiasing would be great!
[14:00]	Zero Linden:	for now, yes, there are far too many messages for us to just redo the protocol all at once
[14:00]	Tleiades Hax:	Hiro ... that is actually up to you :)
[14:00]	Tleiades Hax breathes a sigh of relief
[14:00]	Zero Linden:	Indeed - graphical change must come from within.....
[14:00]	Zero Linden:	er... from how the viewer is coded....
[14:01]	Tree Kyomoon:	so mabey Sony should make a decent SL viewer instead of that ludicrous "Home" thing
[14:01]	Zero Linden:	adding lots of features to the server side of prims isn't going to be high priority for now -- beyond what we do with JPEG/HTML/Flash on a prim face
[14:01]	Zero Linden is not going to take that bait!
[14:02]	Sifu Moraga:	lol
[14:02]	Tree Kyomoon:	:-)
[14:02]	Zero Linden smiles
[14:02]	Frank Bogomil:	sony can't unless we have a well documented/stable protocol
[14:02]	Zero Linden:	:-)
[14:02]	Tleiades Hax:	no, but adding flexible tagging to prims will be
[14:02]	Sifu Moraga needs to try out voice, though
[14:02]	Rex Cronon:	u said "we do" therefore html on a prim is already available?
[14:02]	Tleiades Hax:	prims will need to support spiders, much like web sites
[14:02]	Zero Linden:	no no - not available, but something that is on engineering's plate
[14:02]	Tree Kyomoon:	google in SL
[14:03]	Zero Linden:	I've wanted to add llHTTPServer() for a long time
[14:03]	Zha Ewry:	Makes snese
[14:03]	Tleiades Hax:	well, I suspect linden in SL, more likely :)
[14:03]	Zero Linden:	and then we can just depricate XML-RPC and perhaps email to prims as well
[14:03]	Zha Ewry:	Yes.
[14:03]	Zha Ewry:	One stack, not three
[14:04]	Tleiades Hax:	yes .. I'd love to see only one stack
[14:04]	Sifu Moraga:	XML-RPC RIP
[14:04]	Zero Linden:	Woot - I'm gonna quote you all on that
[14:04]	Tleiades Hax:	better that then the 1 gazillion pages of documentation for SOAP
[14:04]	Sifu Moraga agrees
[14:04]	Frank Bogomil:	yes!
[14:06]	Zero Linden:	went down
[14:06]	Zero Linden:	quick question on llHTTPServer() -- would be enough if that call returned the external URL of the object.... but that URL might change if the region
[14:06]	Zero Linden:	...if the region went down, so that you haad to have it register
[14:06]	Frank Bogomil:	URL would be unique though
[14:06]	Zero Linden:	with some external service you run that would map some constant URL into it?
[14:06]	Zero Linden:	yes
[14:07]	Zero Linden:	so you'd code something like:
[14:07]	Tree Kyomoon:	not a session based URL?/
[14:07]	Sifu Moraga thinks some URL registry would be prudent
[14:07]	Zero Linden:	newURL = llHTTPService(...)
[14:08]	Zero Linden:	if (newURL != oldURL) { llHTTPRequest("http://dyn-sl-object.com/register", [ ] , "my-global-name: " + newURL");
[14:08]	Frank Bogomil:	registry would save bandwidth, otherwise scripts would have to send the URL out every time it changed...
[14:08]	Tleiades Hax:	why not have the prims support the new llsd tcp protocol?
[14:08]	Zero Linden:	well, if LSL only had LLSD in it.....sigh
[14:08]	Sifu Moraga:	sounds like a plan
[14:08]	Zero Linden:	The biggest hurdle to us doing inbound HTTP is the global URL name management
[14:09]	Zero Linden:	if you all don't mind doing that ... then it is pretty easy
[14:09]	Sifu Moraga:	another problems for the asset server?
[14:09]	Zha Ewry:	Global == painpoint
[14:09]	Tleiades Hax:	and the uuid is a no go?
[14:09]	Zero Linden:	well - a UUID is a global thing - we have to keep a central map of UUID to where the object is now...
[14:09]	Zha Ewry:	Which is a painpoint, by definition
[14:09]	Zero Linden:	that is hard -- that is what is so hard about maintaining the current XML-RPC or inbound e-mail
[14:10]	Sifu Moraga:	I think Zha has a point, it would be better to start keeping certain things local
[14:10]	Zha Ewry:	I'm totally ok with needed to do some handshakes, from time to time, to synch up.But.. we need better ways to ensure those get
[14:10]	Zha Ewry:	started
[14:10]	Sifu Moraga:	We already talked about other local assets a few weeks ago
[14:10]	Zero Linden:	Where as, if you object has the URL: http://64.1.2.3:13002/object/12345678-90AB-CDEF-0123-4567890ABCDE
[14:10]	Zha Ewry:	Yep, in the transcripts
[14:11]	Zero Linden:	then it is easy - but your object will get a new URL if the region goes down and comes up somewhere else
[14:11]	Zha Ewry:	That's cheap for the server farm, yep
[14:11]	Zha Ewry:	And you need a way for the other end to know about the change
[14:11]	Zero Linden:	exactly ....
[14:11]	Zha Ewry:	That's the annoying bit. Need a reliable way to trigger the Sim side to
[14:11]	Zha Ewry:	re-breaodcast the new URL to its partner(s)
[14:12]	Zero Linden:	Another option is http://region-uuid.regions.secondlife.com/object/object-uuid
[14:12]	Sifu Moraga:	reminds me of ZeroCOnf service finding...
[14:12]	Zero Linden:	that might not be so bad...
[14:12]	Zero Linden:	but doesn't work for vechicles
[14:12]	Tleiades Hax:	some sort of registry seems to be the only solution I can see at the moment
[14:12]	Zha Ewry:	That is semi-global, isn't it zero?
[14:12]	Sifu Moraga:	(Bonjour for Mac users)
[14:12]	Zero Linden:	Zha - yes
[14:13]	Zero Linden:	but if we wrote a dynamic dns for that delegation point, it wouldn't be so bad.... perhaps....
[14:13]	Sifu Moraga:	Well, an inbound URL is a service, how does ZeroConf do it?
[14:13]	Zero Linden:	Sifu - ZeroConf broadcasts periodically
[14:13]	Sifu Moraga would need to look it up
[14:13]	Sifu Moraga:	Ah
[14:14]	Tleiades Hax:	which won't work because of NAT's
[14:14]	Zero Linden:	and you can ask for anyone to respond with options via broadcast
[14:14]	Sifu Moraga:	that might be ok
[14:14]	Zero Linden:	well - in general, those sorts of things don't work well beyond small networks
[14:15]	Zero Linden:	ZeroConf couldn't handle say 100k objects in world
[14:15]	Sifu Moraga:	I was thinking more of using ZeroConf in your infrastructure, not the clients
[14:15]	Zha Ewry:	Hmm.
[14:15]	Sifu Moraga:	but you are probably right
[14:15]	Zha Ewry:	So, Zero, the issue woudl be , as you say, some single point, which does the rediretcion
[14:15]	Sifu Moraga:	ZeroConf tends to work best in small networks
[14:15]	Zero Linden:	ah- even there - remember over 2000 servers and growing at like 50 a week....
[14:16]	Tleiades Hax:	and a single point of failure/congestion :(
[14:16]	Zero Linden:	well all - I'm going to have go.... back to coding and designing and planning!
[14:16]	Sifu Moraga:	have phune... and thanks for your time
[14:16]	Frank Bogomil:	OK, thanx!
[14:16]	Tree Kyomoon:	2d calls!
[14:16]	Tleiades Hax:	k, I'll go tell my daughter a bed time story
[14:17]	Tleiades Hax:	thanks for you time and info
[14:17]	Sifu Moraga:	Once upon a SecondLife, there was a virtual prince....
[14:17]	Zero Linden:	You holding up your kid? Now I feel bad!
[14:17]	Tleiades Hax:	it is around her usual bedtime :)
[14:17]	Tleiades Hax:	bye all
[14:17]	Sifu Moraga:	Luckly mine are already in bed
[14:18]	Sifu Moraga:	bye
[14:18]	Zero Linden:	See you all on Thursday
[14:18]	Rex Cronon:	bye
[14:18]	Tree Kyomoon:	:)