[sldev] "parcel" media should include the ability to set local host, at least in a HUD instance
Lawson English
lenglish5 at cox.net
Thu Aug 20 04:47:03 PDT 2009
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
More information about the SLDev
mailing list