Jopsy Pendragon

When "HTML On A Prim" arrived on the scene, people reacted to it as if it had been caught sodomizing kittens.

*** Is that still the general attitude towards HOAP?

A little more detail:

I desperately want to use HOAP for a content-creation-tool I'm working on. (it *should* also be possible to use an external browser UI as well, but it wouldn't be as graceful/immersive.) Presuming the tool was something you wanted to use...

*** Would you refuse to use it because of the external web component?


*** Would you use it, but refuse to allow it to render html on a prim in-world?

(Sorry if this is in the wrong sub-forum area)

Loraan Fierrens

While I understand the concern some have about HOAP, it is something I would use and have in the past. One particular example where I can remember it being used to good effect was for the HUD for the Dark Aether Falls game in Babbage. That HUD had an option to go to a browser instead, as I recall... so people had a choice there.

Darien Caldwell

https://marketplace.secondlife.com/p...ol-HUD/3151454
I've sold a lot of these, and so far only 1 complaint about "omg you're going to possibly hack me and see my IP and burn kittens in my name" etc etc.

The biggest issue is that some people have media turned off and I have to help them turn it on. My product generates it's web pages from within the script itself, and only acccesses images and CSS from an external server.

I don't care the RL identity of anyone. (in case it has to be said)

I think people are ready for something better than dialog menus. Go for it.

__________________
[H]arsh Styles

Jopsy Pendragon

I want to do this... but at the moment the widget is just too damned big and javascript laden to fit into the LSL html output buffer's 2048 character limit.

It'd be nice if I could... it'd certainly simplify the feedback process.

Void

lsl output can be up to 40KiB, it's only requests that are cut at 2k, and there's a new function to relax that to 16k?

serving from within LSL is a bit of a pain though... if it's owned by the person that will be viewing it, it's just a minor issue (load to script from notecard), if it has to be generally viewable, you have to bootstrap it via javascript (example here)

as for the core question... depends on what it is and who runs it

__________________
- These eyes can do more than see

Pam Renoir

I've used HTML on a prim, and most of the people I interact with in SL/OS use it too.

Jopsy Pendragon

Well, that's promising! I was under the impression from the lsl wiki for llHTTPResponse the max was 2048, and since my core document without the css/js/php includes is already up to 10k. (obviously I'd remove the php and do the same in lsl if I hosted it from a prim instead)

I'll dig into the teacup example in the morning! Thanks!

Void

Just a fair warning, in the case of Teacup, it expects scripts in the same prim as it to handle link messages the size of the page being sent... anything that can't should either not use link messages, or should be placed in another prim, where the expectations are only 4KiB max (essentially whatever the server received as a request, plus a little overhead). It's really just a fetch interface for specially crafted web pages. it would have to be tweaked to use direct html but it would actually simplify a lot.

currently you can do an LSL virtual proxy of up to 16KiB, by setting the body max length for http requests to 16k (MONO, LSO only allows 4k), then pushing the retrieved page back out to the client as if it was served from LSL. It won't however handle things like cookies at least not directly.

Adeon Writer

I use it exclusively for all media, it's more lightweight, doesn't require a QuickTime plugin, gives much better FPS for video feed, formats are much more compatible, I use it in my (soon to be distributed) YouTube+Vimeo player, as it doesn't require land ownership or bouncing and converting the source off an external server, just connects the watchers to YouTube.com with no middleman.

It's a great feature. More viewers REALLY need to support it, I can't use ones that don't, YouTube parties are a good part of my social scene.

Some don't like the feature because of the floaty address bar, but I'm trying to make it known that there's a script line to hide it.

Trasee Darkwatch

I generally leave media turned off in my viewer, turning it on only when necessary, and when I know what I'm viewing. "Necessary" seems to be very few and far between (not even once a month, typically).

__________________
______________________________________________
(\__/)
(='.'=) This is Bunny. Copy and paste Bunny into your
(")_(") signature to help him gain world domination

Void

I should add that people that trust LSL served content over web served content are actually being silly.... you can still correlate IP address to avatars, you just lose cookie tracking, but you'd lose that effectively anyway because of the implementation of of per avatar/login sessions.... in short, it's no more or less "privacy secure" than other web content for MOAP

Trasee Darkwatch

My concern isn't so much privacy as malicious behavior on web pages. Much more plausible for malicious behavior from a web page than an LSL script, I think.

Void

most of the common attacks are still possible since they rely on cross site scripting, and JSON, you'd be slightly more immune to media attacks, since they'd have to fit within the send limitations of LSL, and be read from JSON wrappers, so it'd be a lot of work.... but it really comes down to "can I trust this source" rather than "can I trust this location"

Jopsy Pendragon

Fortunately, I'm not doing anything particularly fancy (I hope). No cookies, just form & response stuff. For example

http://jopsyinsl.com/test/sample.html

The problem is the form elements get a little bulky what with the range slider and value entry box. I'm at the point of using the included javascript to dynamically insert elements into the form to cut down on repetition or server-side expansion.

Messy messy. :}

I was surprised and pleased to see the in-viewer browser actually supports html5 input-range slider elements.

Darien Caldwell

if your script is serving the page to a Media on a Prim (MOAP) viewer, the 2048 byte limit is not enforced. I didn't know this myself until recent (next update removes my 2k limiter).

it's a very nondescript footnote on the page: http://wiki.secondlife.com/wiki/LlHTTPResponse "This limit does not apply to shared media MOAP " which is probably why I first overlooked it.

Void

that note is slightly misleading.... it's llHttpRequest that truncates what it recieves, but as noted above, that can be optionally increased to 1/4 of possible script memory (4k for LSO, 16 for MONO)...

serving, your only technical limit is what you can cram into the script sending it (~40KiB), and it doesn't matter what the receiver is.

I really must think of some better wording for that caveat because it's tripped up several people.... and I have to admit it's my fault, because I simplified that caveat =X

Darien Caldwell

Yes, mentioning the limits might be good. I tried it out because I didn't believe it at first, and wanted to see for myself. I always use Mono, so tried up to 10k before deciding it really worked. It's a good mention that there still is a 16k limit though. (i don't expect I'd ever need that much for my purposes)

But actually llHttpResponse() used to also cut data to 2048k, (at least I thought, I learned it pre-MOAP) which was why i was surprised it was lifted. A llHTTPResponse() can only be done in the context of a http_request() event (not necessarily inside it, but in it's context) due to it needing a http_request() key. That's completely separate from the funtioning of llHTTPRequest(). I don't even use llHTTPRequest in my script at all, and still get the limit lifted when serving to MOAP.

Are you sure llHTTPResponse() has a limit with MOAP? Now I wonder...

Edit: I successfully passed 28k of data to a MOAP prim via llHTTPResponse(). yay!

Edit Edit: Oh ho! i see what you're getting at now. Even non-MOAP is getting the full 28k. It is a bit confusing. At any rate, i don't have to limit my responses to 2k so I'm happy.

Jopsy Pendragon

On the page for llHTTPResponse, instead of Maybe this would be better?

(I'd edit it myself, but I've a standing policy not to change anything I haven't exhaustively tested myself, and I haven't yet.

Void

new caveat reads:

Jopsy Pendragon

I thought it was http_response that was truncating, since llHTTPRequest's duty is complete by that point.

(otherwise, thanks for popping in the edit!

Jack Abraham

Jopsy, I'd use HTML on a prim written by you, 'cause I trust you. I don't leave it on for the general public to spam me. I'd recommend having it decay to an image that invites the user to touch to load the web page though.

Void

honestly I'm not sure where it actually happens, it may be done with a 'part' flag in the request. but either way http_response event can only be triggered from llHTTPRequest, which is also where they stuck the control for changing the truncation length.

Jopsy Pendragon

Man, I'm still newbish with javascript... but damn am I having fun with this project.

I've set up a javascript form 'preprocessor' of sorts that scans the form definition for elements like:

<input type="vector" id="MY_VECTOR1" class="signed" min="-1.0" max="1.0" step=".01" value="0" />

It then splits it into three parts: {MY_VECTOR1_X, *_Y and *_Z}
Appends an editable numeric display fields to each part.
Prepends a 'click-to-edit icon' that when moused-over pops up a slider control.
Defines the slider control with a type specific background (signed vs unsigned), and min/max labels at the top and bottom, and inserts the inline javascript snippet to sync the slider and numeric field.

Icky looking function but it *greatly* simplifies the form definition and eliminates the need for server-side expansion of form elements!

Wewt!

(Sorry... I just have no one in RL to share my enthusiasm with, their eyes tend to glaze over when I mention this kind of stuff.

Strife

Out of curiosity is it 1/4 of the default max script size, or 1/4 of the scripts set max script size?

Basically does llSetMemoryLimit effect it?

Darien Caldwell

I was given the impression the amount is fixed, regardless of the memory allocated.

I.E. even if you used llSetMemoryLimit() to limit the script to 6k, you could still recieve up to 16k, *if* you could magically finagle that to happen. I think In reality though, you're going to be limited by the size of the memory available anyway. a 16k string received would crash a 6k script undoubtedly.