Scripting User group/Transcripts/2011-03-21

== List of Attendees ==
*
*
*
*
*
*
*
*
*
*
*
*
*
== Transcript ==
[09:01]	:	Hello.
[09:02]	:	Hey Kelly.
[09:02]	 	seat to change your animation or position.
[09:03]	:	Hi Kelly
[09:04]	:	How is everyone doing?
[09:04]	:	Not bad.
[09:05]	:	doing pretty good, yourself?
[09:05]	 	is doing good
[09:05]	:	Doing all right.
[09:05]	:	If I recall correctly today is a triage day.
[09:05]	:	First, what little news I have.
[09:06]	:	Mesh on aditi picked up the 'mono 2 aware' changes late last week. As soon as internal QA gives it another once over we should get the 'mono 2 performance' branch up on aditi this week.
[09:06]	:	woo!
[09:06]	:	Huzzah!
[09:06]	:	wee
[09:06]	:	will try to get it on a lot of regions and let it bake for a few weeks before pushing it through RC.
[09:07]	:	Try and give it a good test once it is up on aditi though, please.
[09:07]	 	nods, "if aditi ever lets me sign on on the weekends"
[09:08]	:	hunh, I wonder why it won't
[09:08]	:	Have you asked oskar about that?
[09:08]	:	no i will though
[09:09]	:	i deliberatly wanted to try to break raycasting to prove falcon wrong
[09:09]	:	but no luck
[09:09]	:	ill tell oskar
[09:09]	:	doh.
[09:09]	:	When will meshes arrive on main grid? They are like a dam holding a flood of good things behind them
[09:09]	:	There is still a lot of work to do for meshes.
[09:09]	:	kaluura theres a mesh meeting in two hours
[09:09]	:	on aditi
[09:10]	:	I'm starting to hate meshes...
[09:10]	:	but they aren't holding up mono 2 work anymore.
[09:10]	:	:)
[09:10]	:	kelly, any luck with amanda on the table
[09:10]	:	for user groups
[09:11]	:	Last week I got slammed with some firefighting work and didn't get a chance to make progress on that.
[09:11]	:	ah alright
[09:12]	:	Right now andrew's user group includes scripting, so for the time being I may just become a subsidiary of that user group and have andrew make a meeting time for this hour in his group's name.
[09:12]	:	That is what I meant to get done last week, but when I was firefighting so was he. :)
[09:12]	 	nods
[09:13]	:	... would been cool to have group hour dedicated to scriptings
[09:13]	:	All right, any general questions?
[09:14]	:	Ok then.
[09:14]	:	http://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage
[09:14]	:	So what kind of stuff will Andrew's group pick up scripting wise? Any idea how things like that will work, scripting issues are getting a bit neglected...
[09:14]	:	Will you concider starting official scripting hours later when you get to work on improving the script stuff?
[09:14]	:	Nothing would change, really. Scripting work is still back-burner right now.
[09:15]	:	I'd like this hour to be official.
[09:15]	:	And ongoing so I'm not starting from scratch when we do get scripting brought back to the front.
[09:15]	:	Also, I think the triages are still useful. However I am open to input on making these meetings more valuable to you.
[09:16]	:	Put it into the UG calendar, that's official enough for us...
[09:16]	:	Right.
[09:16]	:	It'd be nice if even though no scripting work is really being done if things were at least being added to some kind of backlog like Snowstorm uses, as really most of the time is spent being told "not right now" on most issues
[09:17]	:	Then a lot of scripting issues with viewer-side components never see any activity either, as no-one knows that the server-side will ever get done so there's not much point investing time doing the viewer stuff, even ithough it's the open-source stuff that others can work on
[09:17]	:	Haravikk, that is a good point. I will look into getting a visible backlog.
[09:17]	:	we have an internal backlog, but that doesn't help you.
[09:18]	:	Ah, well more transparency would be great in that case, so good luck setting that up =)
[09:19]	:	On the transparency topic, office hour transcripts would help out those of us for whom this is the middle of the RL work day; we'd at least know what's being discussed.
[09:19]	:	Other than that I have another JIRA issue I'd like to ask about once others are looked at on the triage list, otherwise I'll just add it for later if we run out of time
[09:19]	:	yeah I have those saved up I just need to post them
[09:20]	:	Cool; thanks.
[09:21]	:	All right.
[09:21]	:	The twitter message i saw about this meeting didn't really say what subject we would hear or speak about. What aspects of scripting..
[09:21]	:	sorry for my late showup btw
[09:21]	:	http://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage
[09:22]	:	gonna start at the new features there. We skpped SVC-6300 last time because Haravikk wasn't here.
[09:22]	:	http://jira.secondlife.com/browse/SVC-6300 
[#SVC-6300] llStartAnimationSynced() - start an animation synchronised with a given timestamp
[09:22]	:	Hi Haravikk. :)
[09:22]	:	Ah I think we went over that a couple weeks ago, just needs marked acknowledged maybe?
[09:22]	:	ok
[09:23]	:	Done.
[09:23]	:	Though feel free to divert 10 or so Lindens to working on it if possible ;)
[09:23]	:	Aw integer to hex would be nice :p
[09:23]	:	heheh of course. I wish I had 10 developers to devote to anything.
[09:23]	:	SVC-6539
[09:23]	:	http://jira.secondlife.com/browse/SVC-6539 
[#SVC-6539] Constants-based text-entry for llDialog
[09:24]	:	My feeling: No can do... alas...
[09:24]	:	Ah hehe, I think I may have entered most of the current triage list =)
[09:24]	:	Looks that way. : )
[09:24]	:	Basically it's to allow a more modular dialogue once llTextBox() is done, so you can mix and match input and buttons
[09:24]	:	once we get to that level .... why not use html?
[09:25]	:	Would be cool! Ho yeah!
[09:25]	:	HTML has an awful lot of overhead for LSL scripts to work with
[09:25]	:	Would be nice, I think I did post another issue a while back for XML control of SL GUI elements, which would be a little more streamlined though still heavier than a simplified dialogue function
[09:26]	:	Plus if you're talking about using the prim as a web server, Kelly, you're going to set of the media filter each time (on those viewers that have it), raising trust issues.
[09:26]	:	plus theres still that 2048 byte limit on httprequest, though im not even sure if that would factor in the the implimentation being discussed
[09:26]	:	I don't follow Jack.
[09:27]	:	because of redzone, lots of third party viewers have implimented a blacklist functionality on any webtraffic to and from the viewer
[09:27]	:	We came up with quite a few tricks for showing a form straight from LSL, including getting around the 2k limit.
[09:27]	:	If I access media-on-a-prim on Dolphin 2 (which I'm using now), I'm prompted to whitelist, blacklist, allow or deny the sim as a media stream to connect to.
[09:27]	:	Well, seems those could whitelist traffic to LL servers.
[09:27]	:	My understanding is that Oz is considering importing the same functionality to the LL viewer.
[09:28]	:	you don't need a 3rd party server to do basic forms to LSL
[09:28]	:	Could, but they'd then be vulnerable to redirects... a 3rd party server would actually raise fewer trust issues.
[09:28]	:	You can even do MoaP without external server.
[09:28]	:	But the internal server still triggers the white/black list, Kaluura... any URL does.
[09:29]	:	If I remember correctly, writting text on prim with MoaP does't use an URL
[09:29]	:	people are too paranoid in my opinion, which i know is not everyone elses
[09:29]	:	I honestly don't know how they have their whitelist/blacklists working so can't comment on that.
[09:30]	:	By host name, Kelly.
[09:30]	:	draconis, I agree.
[09:30]	:	I assumed that much, jack. I'm just saying this isn't a topic I can really discuss with any authority.
[09:30]	:	Getting a little off at a tangent maybe? Basically while HTML would certainly give the most control, more control of the existing dialogue system would be good too, and suit most simple use-cases better anyway
[09:30]	:	And seems kind of orthogonal. Maybe you won't trust the media on your hud? I dunno.
[09:31]	:	GIven the choice of the two methods, I'd go with Haravikk's both for overhead and security.
[09:31]	:	Gory details:
 llSetPrimMediaParams(4, [PRIM_MEDIA_CURRENT_URL,
[09:31]	:	I don't think we can easily extend the existing dialog function.
[09:32]	:	cept align center isnt standards compliant nor has been with any of the latest versions of html
[09:32]	:	Dialogues currently fail if sent any data other than strings, so insert integer constants is actually fairly easy
[09:32]	:	It works... It's all that matters.
[09:33]	:	you would need css to do it correctly, i think
[09:33]	:	So it's actually possible to make llDialog more like llSetPrimitiveParams for example, without breaking existing scripts
[09:33]	:	Any while not everybody is able to use llDialog(), it's still time to implement SVC-2406
[09:33]	:	http://jira.secondlife.com/browse/SVC-2406 
[#SVC-2406] LSL: Add "prefilled" string to llTextBox
[09:33]	:	Any way,*
[09:33]	:	textbox works in the lastest viewer 2s
[09:33]	:	Yes but not with prefilled strings.
[09:34]	:	would be more a viewer change then a server one
[09:34]	:	It is a neat idea. But I'd be more inclined to include an HTML_FORM constant that accepts 1 string, and allows you to fill it in with some code that will get posted back to the script
[09:34]	:	or other solutions that are more flexible
[09:34]	:	HTML_FORM for llDialog?
[09:34]	:	Hoooo...
[09:35]	:	In future sure, but that requires scripters to be familiar with HTML, and accept the added memory overhead it would cause
[09:35]	:	Felixibility is great, simplicity is necessary.
[09:35]	:	Even a simple HTML form would be a lot more memory intensive than DIALOG_TEXT, "Prefilled value" =)
[09:35]	:	I don't think we're talking about writing a fully compliant HTML file here...
[09:35]	:	<blink>button</blink>
[09:36]	:	that was a joke
[09:36]	:	So if a constants-based dialogue were added HTML could easily be added later, but the simpler option is still better in the short-term I think, and for keeping LSL clean for users that only want simple forms
[09:36]	:	Fully compliant html (well everything that goes in the form tag) would be easiest, but it might be possible to offer some shortcuts in the accepted text.
[09:37]	:	I don't really like the simpler option because I don't think it is flexible enough for the time it would take.
[09:37]	:	I'd rather do it once with something really flexible, and be done.
[09:37]	:	xml would be sufficiently flexible no?
[09:37]	:	Good idea...
[09:37]	:	Are you assuming results returned via http or chat, Kelly?
[09:37]	:	if it is html I can just use the embedded browser.
[09:37]	:	could return them via chat.
[09:37]	:	yeah that would be nice
[09:37]	:	I think that'd address a lot of the overhead.
[09:37]	:	since that would probably be easier.
[09:38]	:	To the condition that the embedded browser doesn't open fullscreen like it currently does/did for the the profiles
[09:38]	:	I had a similar proposal with XML under SVC-3045
[09:38]	:	http://jira.secondlife.com/browse/SVC-3045 
[#SVC-3045] Allow HUDs to create native GUIs
[09:38]	:	No it would be a smallish floater, in a corner, similar to dialogs.
[09:38]	 	really liked that one.
[09:39]	:	considering the ui is mostly xml, i would imagine it would make more sense with less overhead to use xml
[09:40]	:	The xml used in the client is anything but slim...
[09:40]	:	not everyone likes our ui's xml
[09:40]	:	HTML has other issues though such as creating dialogues that could try to impersonate other things. And the cost in sending even XML strings around all the time is still reason enough for a simplified approach such as a constants-based list IMO, especially since we're supposed to be trying to reduce the size of scripts =)
[09:40]	:	you don't get dialogs that often to have to worry about how much data it's sent from the sim
[09:41]	:	if you teleport around to stores, thats all you get, dialogs
[09:41]	:	But a script capable of handling three or four different types of dialogue will quickly balloon in size
[09:41]	:	draconis, for the price of 1 texture when you teleport around you can have 10000 dialogs
[09:41]	:	Haravikk: what I imagine is that the string provided would be what is inside the <form> and </form> tags (not the tags themselves). The dialog that pops up could be made to look distinctive as well.
[09:41]	:	yes, i am well aware how terrible textures are latif
[09:42]	:	hi all. is this in voice?
[09:42]	:	kelly, just send to script what the form would post to web site ayway
[09:43]	:	nope
[09:43]	:	We could strip any thing from the provided string that we wanted as well to sanitize.
[09:43]	:	And yes, exactly latif.
[09:43]	:	like: field1=val1&field2&val2 ...
[09:43]	:	That might be okay, but still, why enforce HTML? HTML forms are just a set of a few standard elements in a list usually anyway, most of which are already available in viewer 2's GUI, so a constants list is plenty powerful for the majority of uses I think
[09:43]	:	That is the string the script would get in chat.
[09:43]	:	it is way easier to implement Haravikk.
[09:44]	:	No OO. I don't even have my headset on.
[09:44]	:	probably more secure too. you don't want SL scripts to send xui and potentially crash the viewr
[09:44]	:	And HTML isn't that hard. With a few examples, anybody can learn the needed basics.
[09:44]	:	it's much harder to crash xui than webkit
[09:44]	:	But it's not way easier to use except for people that are already familiar with HTML, and even then they're still doing extra work to put together a few simple elements. It also has a lot less testing and security concerns to have a simple set of constants
[09:45]	:	testing and security? i think webkit gets plenty ;)
[09:46]	:	Not webkit, to make sure the system can't be abused or produced unusual results, if we have a bunch of LSL scripters with little or no knowledge of HTML then they will quickly start creating forms with unusual results
[09:47]	:	If you give a html flotar, which is rendered by built in webkit, the potential for abuse is very small compared to exposing xui.
[09:47]	:	I'm not talking about comparison to XUI, but to LSL constants
[09:47]	:	(the original issue on the triage list)
[09:48]	:	I think dialog and textbox solve the really simple cases of simple buttons or simple text. I think once you get past that you want layout and flexibility. I don't think another simple option is needed that isn't really flexible since we will immediately realize 'oh this almost works except I need it to do this other thing"
[09:48]	:	kelly +1
[09:48]	:	If html is too hard, ask one question at a time.
[09:48]	:	We would end up in a constant stage of 'almost good enough'
[09:48]	:	are we following an agenda or can i get in?
[09:49]	:	a LSL scripter shouldn't complain about html being too complex ;)
[09:49]	:	OO http://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage and SVC-6539 right now
[09:49]	:	One an have html knowledge prior to SL so that could be an advantage or disadvantage.. I don't think learning curve is that much at stake here
[09:49]	:	takes about 3 min to learn <form></form>
[09:50]	:	Sure... No fancy styling or anything... Bare HTML.
[09:50]	:	I'm gonna close this one haravikk as won't finish and put my thoughts in a comment.
[09:50]	:	The constants list can be used for things like colour or position entry, entering several names into a security scanner and so-on, there are plenty of simple cases that aren't covered by llTextBox() but for which HTML is overkill
[09:51]	:	html is not overkill you can make it as simpel as you want
[09:51]	:	yes, we would have to constantly be extending it with our own custom language, essentially, forced into list format. It gets ugly quick.
[09:51]	:	I'd like to move on to the next jira, if that is all right?
[09:52]	:	It's not quite list format, it's the same format as button dialogues, so you can make items up to 3 button-spaces wide
[09:52]	:	<form>Please enter your sekrit code <input type="text" name="code"> <input type="submit"> </form>
[09:52]	:	I meant the language to define your dialog is forced into list format
[09:52]	:	we would be defining a layout language that has to fit into an LSL list.
[09:52]	:	True, but LSL scripters are already using that on a daily basis with llSetPrimitiveParams, llParticleSystem etc.
[09:53]	:	i love particle system to death, but its old and broken
[09:53]	:	I see an obvious fear and hate of change.
[09:53]	:	that's only because LSL is limited and there is no other option ;)
[09:54]	:	But it works, if LSL gets other data-types then by all means create a new way of entering those things, but it's still a lot simpler, cleaner, and leaner than HTML IMO
[09:54]	:	I'd love to have another option. :) In this case, for dialogs, there is a world standard. HTML and forms. I don't want to design my own language for something already solved the world over.
[09:54]	:	yup
[09:54]	:	Then why does LSL exist? =P
[09:54]	:	Yeah... Re-inventing the wheel is never a good idea.
[09:55]	:	Haravikk: I'd love to have something besides LSL as well. :)
[09:55]	:	Haravikk, I'd much rather code in c# if Kelly ever gets a go ahead to finish it ;)
[09:55]	:	Ah, another thing for me to learn. : )
[09:56]	:	Learning is good for you!
[09:56]	:	Yep.
[09:56]	:	Kelly this may interest you - Ordinal Malaprop and Yoz today had a Twitter conversation about HTTP, LSL, better data structures etc. - go to https://twitter.com/ #!/ordinal or https://twitter.com/ #!/yoz
[09:56]	:	If we were doing this in C# it wouldn't be the same problem, but I don't think shoe-horning HTML into LSL for something basic like a dialogue is a good idea, not for basic object interaction
[09:56]	:	For basic use lldialog and lltextbox
[09:57]	:	Haravikk, it's not shoe-horning, it's what HTML was designed to do and what's used for on billions of pages out there.
[09:57]	:	Creating input forms
[09:57]	:	I hate trying to follow twitter conversations between any two people when one isn't me.
[09:58]	:	I'll send you an email if that's ok.
[09:58]	:	any c syntax language, and xforms should have gotten better acceptance than it did i think
[09:58]	:	OO I talk with Yoz everyweek about scripting, but sure go ahead.
[09:58]	:	i want more Twitter support in the viewer and it seems HUDs are not good
[09:59]	:	see https://jira.secondlife.com/browse/STORM-9 for an alternative proposal
[09:59]	:	[#STORM-9] As a User, I want to share my location and a custom status with friends on Twitter so they can follow what I'm up to in Second Life.
[09:59]	:	i thought Yoz was web and social and those sorts of things, not server and sripting
[09:59]	:	written by esbee. it's about a native support in the viewer
[09:59]	:	rather catForum support than twitter support
[09:59]	:	yoz is yoz
[09:59]	:	Hmm, I got logged out =(
[09:59]	:	Ok, I have another meeting in 1 minute.
[09:59]	:	take care kelly
[10:00]	:	Thanks for coming out for the unofficial scripting group.
[10:00]	:	Later Kelly.
[10:00]	:	thanks Kelly
[10:00]	:	YOu're unofficially welcome.
[10:00]	:	take care Kelly
[10:00]	:	Till next time everyone
 
Generated with SLog Wikifier