I suspect a bit of work is needed both on the server and HG link
handling end and in the viewers to really make this MUCH simpler and
regular. Especially for new and infrequent users its essential this
is simplified and works wherever one might expect.
Jeff, I took the liberty of pasting in your notes to the Firestorm
JIRA with credit to you. let me know if you feel uncomfortable with
that and I will remove the comments.
It was introduced by Armin Weatherwax for Kokua and Firestorm over a
year ago. I don't know the history of it, just the scheme. It can be
registered with IANA when it's finalized, possibly for FS 4.4.6. It's
more than just replacing trademarked syntax. I'll write something up
about it from what I've gleaned from Armin's commits.
Bear in mind, this is not a Firestorm specific scheme. It originated
in Kokua for adding grids to the gridlist from the web and grew and
is present in all hypergrid enabled V2/V3-based viewers for OpenSim.
I am only speculating as I really don't know if the hypergrid address
formats all have their place... but I do wonder if as a target
OpenSim can get behind the hop:// format now we have a split in
OpenSim and proprietary naming and handling of protocols for
secondlife:// in viewers.
can we make http:// where needed or hop:// work everywhere in this style... ?
Thanks for the extra information now flowing. And thanks for that
pointer to the earlier discussion on the very same point Fleep.
I really think the time is right to get this sorted out ... we have
the ears of the core developers in some TPVs and some now are looking
seriously at the OpenSim issues with the opportunity now created by
having to have an OpenSim variant of every active viewer to exclude
the havok licenced code.
There is no need to stop odd URL variants being supported in viewers
that already can handle them - like the double colon format that
emerged at one time... but we need to go forward into a future with
many types of virtual world platform connected by standards compliant
systems in future - not just focus on OpenSim to OpenSim
grids). That's the appeal of a non-platform specific URI protocol
prefix like hop://
And perhaps its a matter of adopting a single style and then going
with that to fix (or at the very last radically simply and improve
So, a proposal is as follows... that inter-grid valid teleport
indications are characterised by a standard form as follows:
Relevant parts ought to be able to be left out if that makes sense...
but not at the expense of making platform or region size assumptions.
the landing places ought to be left unspecified if the hop:// is
ambiguous rather than bundling in such assumptions to the protocol
specification, though any specific implementation could use platform
knowledge of course.
default gridname:port uit to imply the address is onky valud on the
local grid. But i the gridname:port is present it should also work
even if its used on that grid (this is not the case in the present
handling of hop:// in some viewers).
default port is the HTTP default port 80 (not a platform specific port)
x,y/z in units of a metre, decimal point allowed.
Final / optional
Melanie makes a very good point about how to bring in SSL grid login
URIs. There may be a good way to do this for those familiar with
designing such protocol handlers and the syntax of the URIs... but a
simple scheme would be for the protocol handlers in viewers to try
http://gridname and if that fails then fakll back to try
https://gridname before reporting failure. Redeemer its only a
HANDLER.. so need not fully reflect the underlying calls tried or made.
Re: Hypergrid Things, Jumps, SLurls, Hop URLs and Maps
On 10/06/2013 23:53, Ai Austin wrote:
> Melanie makes a very good point about how to bring in SSL grid login
> URIs. There may be a good way to do this for those familiar with
> designing such protocol handlers and the syntax of the URIs... but a
> simple scheme would be for the protocol handlers in viewers to try
> http://gridname and if that fails then fakll back to try
> https://gridname before reporting failure. Redeemer its only a
> HANDLER.. so need not fully reflect the underlying calls tried or made.
For Avination, the above approach would result in failure. The HTTP
variant of the login server serves grid info only, but it DOES
exist, resulting in the http "semi-suceeding" and https never being
I also thought about the hops:// suggestion after I mailed last
night... "hop secure"
The other format is not a valid URI so should not be
suggested. That's also the problem with using two : and forms with
spaces between elements. Spaces inside an element are fine as they
are simply replaced with %20.