[sldev] "parcel" media should include the ability to set local host, at least in a HUD instance

[Lawson English]

As usual... I'm not making myself clear...


The point is NOT to  allow access from a HUD to any arbitrary parcel 
media, regardless of who owns the land the avatar stands on (that's a 
separate issue), but to enable the avatar to enable localhost media to 
interact with the HUD without requiring ANY land/parcel relationship 
whatsoever. A secondary concern would be to allow enabling of the media 
URL for any URL that the user deliberately selects from their HUD (not 
an arbitrary object found somewhere on some bit of land).


Example usecases for the first instance: A user has downloaded a special 
plugin that interacts with the client in order to provide better 
manipulation of inventory or estate management. Rather than require a 
separate browser page, as is the case now, a user could simply point the 
browser to a localhost page that controls the plugin. The media plugin 
HUD is merely acting as a more immersive version of what already can 
(and is being done) by pages served by libomv Gridproxy plugins. If the 
user choses to have a separate webpage for such a control panel, they 
can already do so, but if one allows the HUD's media URL to point to the 
local webpage this would provide a nicer-feeling interface to whatever 
client enhancements someone has obtained. THIS CAPABILITY ALREADY EXISTS 
but only if you direct a browser (SL or external) to the localhost page 
served by the gridproxy plugin.

There are also usecases where having the ability to set a HUD's media 
URL to localhost without a genuine plugin (gridproxy or otherwise) would 
be useful.

E.G., if a user downloads the seaside webserver ( http://www.seaside.st 
), they get built-in, a reasonably robust blog they can personalize for 
their own private use, to allow storing notes and so on. Additionally, 
localhost webapplications can be used to provide other useful Second 
Life enhancements, regardless of their relationship with the media URL 
plugin and/or gridproxy-style plugin. E.G., an HUD based drawing app, 
such as http://canvaspaint.org/ , which already works with the llMedia 
plugin app or a web-based version of http://www.secondplopp.com

More robust web applications could be integrated quite easily with 
Second LIfe using a combination of the llMediaPlugin plus a hypothetical 
eventshandler plugin that I've already mentioned to some LIndens that 
would provide some gridproxy capabilities without the man in the middle 
proxy (just funnel specific packets and other internal client events to 
registered external handler plugins for 
manipulation/enhancement/injection, much the way the llMediaProxy is 
designed to do for simple GUI events).


E.G., semi-professional building tools, for prims, sculpties AND mesh, 
could be created and run client-side using the llMediaPlugin in a 
HUD-based interface and allow for injection/display/uploading of the 
finished product without extra steps that detract from the "in-world" 
immersion.

Whiteboards are possible already using the llMediaPlugin, but would 
require ownership/access to a public website, which limits their 
usefulness, and currently require that one have parcel media control 
anyway, which also limits their usefulness. The ability to point a HUD 
or even a prim media URL to an arbitrary external URL would enable 
ad-hoc whiteboards that would work at any arbitrary moment. The ability 
to point a HUD or prim URL to localhost might enable more sophisticated 
whiteboards like Croquet-on-a-HUD, where the Croquet client (or moral 
equivalent) is providing the peer-to-peer capabilities for participating 
avatars who have established their own P2P connections behind the scenes 
using whatever external app is suitable.


The ability to use a  HUD with an arbitrary media URL that isn't 
controlled by parcel access should be obvious. It extends the LSL 
Browser HUD model to allow control of external apps with clientside (or 
client-side LIKE) scripting rather than LSL-serverside apps, and allows 
true immersion. Localhost URLs are the most easily controlled by regular 
users, and should be the first to be enabled for this purpose. Less 
restrictive options can be tested as time goes by both for HUDs and 
non-HUD prims.

Greater synergy can be obtained by using a hypothetical external events 
handler plugin combined with the llMediaPlugin. I'll list a few of the 
possibilities in another post. Be warned: the possibilities are, for all 
practical purposes, limitless.

Lawson




































Celierra Darling wrote:
> To support being able to pass media URLs to agents without an 
> associated parcel, I'd direct attention to the spin-off issues 
> (SVC-4272, -4273, or -4274; I think *SVC-4273 
> <http://jira.secondlife.com/browse/SVC-4273>* is most relevant here). 
>  That did look useful, but it was a bit of a hack, and it probably 
> would have been only a matter of time before the lack of that parcel 
> check would have caused trouble or at least annoyance (ex. something 
> scanner-based radiating into adjacent parcels accidentally, perhaps). 
>  But I hope they do turn around and provide one of those better 
> suggestions in its place.
>
> Celi
>
> On Tue, Aug 18, 2009 at 7:05 PM, mitch at mckenzie.ws 
> <mailto:mitch at mckenzie.ws> <mitch at mckenzie.ws 
> <mailto:mitch at mckenzie.ws>> wrote:
>
>     Hi Lawson,
>
>     I had a hud that does alot of what you are talking about, even had
>     a way
>     to implement it that avoided silly parcel limitations by using a
>     single
>     antenna in the sim to make the media call to the agent, not the
>     parcel,
>     but then Soft Linden decided to kill it off and call it a "Bug" after
>     several years in active use on the main grid with out a single
>     compliant. You can see the nasty history here:
>     http://jira.secondlife.com/browse/SVC-4133  ... They decided it
>     could be
>     used to harvest I.P.s even though the current parcel system allows for
>     simple I.P. harvesting just as it sits today.
>
>     I still have some levels of functionality available, but not near the
>     simplicity for users as it was before they killed it off.Hollar and I
>     will show you my examples in world..
>
>     Media Hax
>
>
>
>     Lawson English wrote:
>     > Lawson English wrote:
>     >
>     >> I think the problem is that there's no way for a non-land-owner
>     to SET
>     >> the url in the first place.
>     >>
>     >>
>     >>
>     >
>     > Just to clarify: right now,  you need to have the ability to set the
>     > parcel media URL. When people start producing custom plugins for the
>     > media plugin API, that limitation will still exist, as far as I
>     can tell.
>     >
>     > What is needed is a way for someone to be able to set a media URL or
>     > plugin equivalent that is independent of the parcel media URL.
>     >
>     > The private URL could be directed to a localhost server, or to a
>     private
>     > server, or whatever.  With a bit of clever hacking, it MAY be
>     possible
>     > to integrate existing/future collaboration tools into SL that work
>     > independently of the parcel media. FOr example, if a group of people
>     > want to play multi-person tic-tac-toe in a HUD, there should be
>     a way
>     > for them to privately arrange a URL or other connection to a central
>     > server or to each other, independently of there ability to set the
>     > parcel media URL.
>     >
>     > ALong those lines, it would be valuable for businesses to
>     individually
>     > set a URL for each person interacting with a prim. That way, several
>     > different webpages, plugins, etc could be used, each directed to a
>     > specific avatar. Personalized tech support would be possible
>     this way,
>     > for example.
>     >
>     >
>     > Of course, the ultimate implementation of this idea would be
>     > Croquet-on-a-HUD, which might actually be doable with the new
>     media plugin:
>     >
>     > http://www.youtube.com/watch?v=NLMkc7sI2-w
>     >
>     >
>     >
>     > Lawson
>     > _______________________________________________
>     > Policies and (un)subscribe information available here:
>     > http://wiki.secondlife.com/wiki/SLDev
>     > Please read the policies before posting to keep unmoderated
>     posting privileges
>     >
>     >
>     >
>
>     _______________________________________________
>     Policies and (un)subscribe information available here:
>     http://wiki.secondlife.com/wiki/SLDev
>     Please read the policies before posting to keep unmoderated
>     posting privileges
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges