On Thu, 2007-03-29 at 14:51 +1000, Brett Nash wrote:
> > Looks almost okay. The URL (given to a client) can start with any of the
> > following,
> > 
> > tp://
> > tps://
> > http://
> > https://
> > tphttp://
> > tphttps://
> 
> Cool - can we say http and https are deprecated?

I would like clients to accept http/https urls as if they where tp+http
or tp+https

<snip>

> Good - The tphttp one is ugly enough ;-)
> 

I think replacing tphttp with tp+http and tphttps with tp+https would be
a good idea.

I can imaging tp+ssh and tp+dns in the future :P Got to let people play
at work and school! 

> > >  The (.*) is there for http only I assume?  (I assume it is needed for 
> > > http)
> > 
> > The (.*) is the "game name". On servers which have only one game it can
> > be ignored. On servers which have multiple games it should be appended
> > to the username.
> 
> That doesn't make sense?
> 
> If the game is 'testgame' my url is:
>  tp://[EMAIL PROTECTED]:[EMAIL PROTECTED]:port/testgame
>
> Note that URL - two '@' and two ':' - both optional is a nightmare to
> parse.  I think it can't be ambiguous, but I can't prove it.
> 

The two @'s seem ambiguous to me. Can you come up with a regex/code
which works fine with this format? I'm only using the trailing bit to
mean the game because I couldn't.

> For http servers I want the trailing data to be for the HTTP request to
> get the correct location: So I don't have to only run a TP server on my
> root.  eg 
>       tphttp://server/path/to/tpserver

That seems reasonable. 

The specification mentions that the client should request a random place
in the location to avoid broken proxies.
http://www.thousandparsec.net/tp/dev/documents/protocol3.php#HTTPTunneling

This wouldn't work with how we do HTTPS tunnelling however (as you just
tell the proxy to connect to do a HTTPS request to the TPS port).

> Also how does http authentication work along with tp authentication?

It doesn't. HTTP authentication is not supported (and I can't see any
reason to add support for it?). Proxy authentication is another matter
and should be handled.

> > scheme registration process?
> 
> You can register schemes so no-one else can use it - avoids the 'dns'
> issue[2].  Probably not ready for TP yet... but hopefully will one day.
> Info is available in a number of places:
> http://ietfreport.isoc.org/all-ids/draft-hansen-2717bis-2718bis-uri-guidelines-01.txt
> 
> > The tpclient-pywx registers for tp, tps, tphttp and tphttps links in
> > Windows and Gnome.
> 
> Shall look at registration for similar in my client as well.

It's quite easy to do via a gconf call. You can even just call the
command line program.

> > > And can this be put up on the website, or if it is there, linked from
> > > the protocol doc ;-)
> > 
> > It'll go in the protocol4 document.
> 
> Cool.

Feel free to add it and then send us a patch :P

>       Regards,
>       nash

Tim Ansell

_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel

Reply via email to