Jump to content

SIP, Teacup, Red Tea...

Void Singer

Recommended Posts

  So I've been playing around with MOAP and LSL's HTTP-in, which lets you not only display media inworld, but also serve it from there to the Outside world as well...

  Thanks to the work of several people. We can now align/resize the window by script, use "data: URNs to feed non-plain-text content to the window, even using it to wrap things like videos, and.... bootstrap plain text content into HTML pages...

And that's where I've been looking to make improvements. Currently there are two freely available methods for bootstrapping; One uses huge "data:" URN wrappers for all links, but supports mostly normal click through behavior. Unfortunately, at ~three hundred+ bytes per link, you won't be putting many links on your pages. And not all external browsers may support it (I know Firefox does though). The other chooses to hot load the "data:" URN wrappers from the script which can support bigger pages (no huge links), but resets the view for everyone to the last link clicked (could be a good thing in some cases). And completely falls apart outside of prim media (can't be used in the internal browser or external browsers)

Those Methods are vast improvements over the simpler limits we had, but neither is really a good media server

The Goal:

  • Use lsl HTTP-in to serve MOAP, without any external resources, using simple standards based methods. A Server In a Prim or SIP.

The Hurdles:

  • Viewer doesn't pass "data:" URN's to external browsers (even when supported)
  • ll*PrimMedia* Commands are slow (1 sec pause for each call)
  • Script-size (with code) limits page-size drastically
  • HTTP-in can only serve plain text data

The Workarounds and their limitations:

  • Wraping pages in data URNs
    • (+)Gets the HTML onto the page
    • (-)Requires slow media commands
    • (-)Does not work in internal/external browser
  • Wraping links in "data:" URNs:
    • (+)Gets the link HTML onto the page
    • (+)Works on internal/external browser
    • (-)links are HUGE taking up valuable space
  • Wraping pages in java script
    • (+)Gets the HTML onto the page
    • (+)Works on internal/external browser
    • (-)Only get a single page from loading
    • (-)Requires one of the "data:" URN wrapper methods

  Enter the Teacup Server; a next step improvement building on the current methods. A single call of the Prim Media commands, which loads a single initial page, no massive links, no over-sized wrappers (page wrapper is < 1/4 of the minimal HTML it replaces). Pages support most of their normal features (HTML, JavaScript, and CSS, with few restrictions), that would be available within the body tag of a page. All in a minimal LSL script allowing it to safely serve content up to 40Kb+

  But you can't have a server without a file system to fetch from, and you can't have a Teacup without Tea, so I've also coded a simple yet solid example called Red Tea. Red Tea let's you drop notecards in with page content, then it reads the notecards, makes the changes necessary for JavaScript wrapper compatibility, and stores them until the server asks for them. As a bonus, there's Saucer which detects if the files system doesn't have a file, and tells the server so that the server can send the appropriate code right away; that way, page loads aren't held up by missing content.

  "Yeah all this talk is nice, but where is the code?" a Very smart question, and the answer is to click on image below wherever you see it. =)


Link to comment
Share on other sites

oh it ain't perfect yet.... but that did make it a whole lot easier didn't it? =)

it's still got major drawbacks, and I could definitely use some assistance from anyone that's a javascript expert and up to dat on current stuff.... as it is I'm years hacks in there from 2009 at best.

and of course the file system is dinky.... it was just to showcase formatting, and get it to the point I could demo it (hint: if you are in the Scriptoratti group a working version went out just a bit ago with full perms)


what I'd REALLY love, is some feed back on how well it's working, what else people want ti to be able to do, and of course any bugs that I don't already know about....


I see you've been busy answering questions correctly and your Icon turned purple =)

about your question, if it's something to do with improving the land access management tools, then the naswer is "maybe" lol

Link to comment
Share on other sites

This is definitely cool, Void.  This is one of my personal blind spots in LSL, not for lack of interest but because I simply haven't had the time or a client demand  that would have forced me to buckle down and wrestle my way through all the details.  This may be what gets me over my inertia hump.  Thank you. 

Link to comment
Share on other sites

Rolig Loon wrote:

I simply haven't had the time or a client demand . 

Exactly Rolig.  Next month I really had planned to work on making my own in-house communications HTML on a prim instead of hovertext. Now that should be a bit easier :-)

&  @ Void - is this an advisors-only thread?  I'm not sure about giving correct answers, just procrastinating as usual.  Still I'm well into the 'polished' iteration of my PHP system so progress is being made.  (Ironically enough it's the SL side that's slowing me down at the moment.  Need to record loads of texture-offsets and I can't be bothered right now).

Link to comment
Share on other sites

v2's poor reception by the large majority of new content generators and novel creators really set back the use of this feature...

with the option and control hungry crowds of phoenix content creators now being pushed towards what they see as a finally viable featureset for v2 in Firestorm, the desire to option mesh creation, I saw it as something that was going to get a lot more use, and didn't have a simple usable or standardized interface yet.... it was missing that simple and compact methodology that xPose MLP and nPose provided for interactive furniture. and the people who've been around remember the explosion in content and ideas resulting from those becoming available...

I got started on it because tossing 50 records of two peoples names, plus actions taken, plus timestamps, out to chat on demand was a bit.... harsh. and I wanted to add information, like links to the people involved, or locations, and maybe even flesh out the actions. Chat and dialogs just weren't cutting it.

I fully expect to see custom and private monetized back ends for this, heck I'm counting on it so that applications can take off and I (and everyone else) can benefit from having a multiple developers working on multiple projects that suit multiple (and maybe even not previously imagined) needs...

of course that means getting people to try it and use it first =)

Link to comment
Share on other sites

yeah, I revamped the wiki pages with updates and code striaght from the inworld model I was working with. the new codes and pages include several tweaks and corrections, and a simplified "quick start" that gets everything loaded nicely in no time flat an no heavy lifting (and I walked the steps myself to make sure it all ran smoothly)
That page cab be found over here

since you informed me about the bugs though I dug into it and spit out two new jiras.... and decided to disable the touch to load functionality, so it's not going to work for viewers without shared media right now

the jiras are

  • VWR-25554 Internal Browser URI's truncated by llLoadURL
  • VWR-25555 Viewer fails to pass Shared Media and llLoadURL "data:" URN's to external Browsers

related jira I found while building this

  • VWR-25474 Editing a prim w/ Shared media causes continual refresh of media

feature requests related to shared media that I recently filed because of this project

  • VWR-25475 Force HTML parsing in Webkit when mimetype is text/plain and extension is .htm or .html
  • SCR-34 Autofill the Location Header field for llHttpResponse, when the status is 3xx
Link to comment
Share on other sites

especially not with at at least weekly restarts wiping their urls which are also hideously long and the inability to server things like images or video or sound.. never mind the inability to write directly to notecards or scripts, so no easy WISYWYG or even rich text editors.

and they wonder why no one is using it (for media anyways)...

but at least one good thing  came out of it... I coined an acronym and got someone to use it! =D

Link to comment
Share on other sites

  • 2 weeks later...

annnnnnnnnnnnnnnd, we haz update

v0.5 is live on the wiki (click the picture in the original post)

now has support for inline script elements in pages, faster page loads, Title support for external browsers, and a few other goodies

Link to comment
Share on other sites

  • 6 years later...

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now
  • Create New...