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, [email protected] > <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> 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 _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
