Talk:LlSetContentType

2016-02-12T05:59:19Z

Susan Koltai: Wondering why there is no CONTENT_TYPE_CSS

== Too many Questions ==
we (will) have a pretty new function, but zero information about it...
only works for LL's browser / MOAP? (seems like a strange limitation.)
only works for the prim owner? (hows that going to work with the internal browser / MOAP, user key/name isn't sent except from llHTTPRequest)
I can assume it only works for the script that received the request (since normally other scripts can't respond)

if someone has some better info, it'd be really helpful... if all the above are true, it has zero value, since html from llHTTPRequest can't be displayed as such. if it's just limited to html within SL, it has no use for exporting interface of inworld to the web, but more use for things like huds and distrubuted inworld networks. -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 15:29, 5 August 2011 (PDT)

:"for things like huds and distrubuted inworld networks" I think this is exactly the intended use. The exact wording in the release notes was <code>CONTENT_TYPE_HTML "text/html", only valid for embedded browsers on content owned by the person viewing. Falls back to "text/plain" otherwise.</code> The implication is that this is to be used with {{LSLGC|Prim Media}}; which should be made clear (and isn't) in the caveat or description. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 10:20, 6 August 2011 (PDT)

The intended use is to enable HTML based HUDs. I have created an [[HTML_HUD_Demo]].
 For the technical nitty gritty:
* The server will check if the user-agent string contains Second Life and revert to text/plain if it doesn't.
* The server will check the incoming IP of the request against the IP of the object owner and revert to text/plain if they don't match.

For HUDs this will work as expected. Non-HUD content may have weird behavior:
* You may set a custom user-agent string to include Second Life in a non-SL browser to view these urls while logged into the region with the content.
* If you run multiple clients from the same IP and logged into the same region you may be able to see HTML rendered content cross-account.
* Poxy and IP anonymizing services are unlikely to work well with this.

In general these are rare and unreliable enough to sufficiently reduce the concern for hosting webpages under the Linden Lab domain name. This feature is *not* meant to enable serving general purpose web pages from LSL scripts.

: [[User:Kelly Linden|Kelly Linden]] 14:25, 26 August 2011 (PDT)

:: any hope of opening this up to any browser with the secondlife user-agent string? that'd still keep it out of the wider internet and the association clean, while enabling wider use cases within SL. -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 12:46, 30 August 2011 (PDT)

== Caveat ==
I wonder if the Caveats is applicable to the new content types:
* CONTENT_TYPE_XML application/xml
* CONTENT_TYPE_XHTML application/xhtml+xml
* CONTENT_TYPE_ATOM application/atom+xml
* CONTENT_TYPE_JSON application/json
* CONTENT_TYPE_LLSD application/llsd+xml
* CONTENT_TYPE_FORM application/x-www-form-urlencoded
* CONTENT_TYPE_RSS application/rss+xml
[[User:Techplex Engineer|Techplex Engineer]] 10:20, 12 July 2013 (PDT)

== Multi page HUDS ==
Why is there no CONTENT_TYPE_CSS defined? Am I missing the point, why it is not required? If you have HUDS with multiple pages would it not make sense to have a common style sheet resource in the HUD script, which can be loaded into the various pages via <link rel="stylesheet" type="text/css" href="/mystyles.css" > ? Or is there a trivial workaround to get this done?

: this ''should'' only apply to the html setting, but I don't want to update the entry without testing first. -- '''[[User:Void_Singer|Void]]''' ([[User_talk:Void_Singer|talk]]|[[Special:Contributions/Void_Singer|contribs]]) 12:51, 12 July 2013 (PDT)

Talk:LSL Protocol/Ganymedia OpenMAIP v1.0 Specification

2013-02-06T05:18:00Z

Susan Koltai:

Alpha status as this draft has,
I miss the specification on how IP Address assignment and service discovery works.
Also, specifics as to ad-hoc configuration and region handover (in case of avatar attchments) seems to be missing.
Question: If chat is the predominantly used transport, does this imply llRegionSay()?
Question: Is there information on message overhead available?
Question: How scalable is that? Imagine you have a region with 30 avatars, each with 5 attached prims implementing a service or looking for services...what would be approximately the basic chat messages/minute load, service related traffic excluded? (Pure infrastructure).

An alternative solution could be to use a (linden labs provided) or third party infrastructure, serving 2 purposes:
1. Service discovery (I was using a google app engine self-written service discovery in some of my tests in that area). Distributed service discovery like bonjour has its charms, but so has a lag-free SL experience. For inspiration, check back the multicast messages sent by dns-sd, for example.
2. Relaying and region handover management. (The attached scripts detect region change, adjust their address with the infrastructure. Communication uses 1 level of indirection to address communications partners.) Transport protocol negotiation and optimization could be managed by such an infrastructure as well. E.g. to allow to fall back to lsl chat transport if both communications partners happen to be within chat range/same region).

Talk:LSL Protocol/Ganymedia OpenMAIP v1.0 Specification

2013-02-06T04:50:23Z

Susan Koltai: Created page with "Is the specification incomplete? I miss the specification on how IP Address assignment and service discovery works."

Is the specification incomplete?
I miss the specification on how IP Address assignment and service discovery works.

Second Life Wiki - User contributions [en]

Talk:LlSetContentType

Talk:LSL Protocol/Ganymedia OpenMAIP v1.0 Specification

Talk:LSL Protocol/Ganymedia OpenMAIP v1.0 Specification