[Bug 23640] [regression] Re-implement proxy support

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=23640

--- Comment #6 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-09-07 09:30:55 PDT ---
(In reply to comment #5)
> First thanks for this review. I've done the fixes in separate patches that I'll
> sqash later, this way it's easier for you to recheck that I have not done any
> mistakes.

Thanks, that's ideal. To be honest, it's not really necessary to squash them
later, but do that if you like.

> Improved commit message:
> http://git.collabora.co.uk/?p=user/nicolas/telepathy-gabble.git;a=commit;h=d87799deb33c10940b7c99c6104d07ccd57280ed

Thanks, that's much better.

> > Possibilities:
> > 
> > * use commas anyway
> > * use colons, support URI-style IPv6 literals like [::1]:5222 (hard,
> > pointless?)
> > * use colons, don't support IPv6 literals, assume that anyone with working IPv6
> > will also have working DNS
> 
> I had to switch to comma because : clash with IPV6 has you mentioned and ;
> clash with Mission Control serialization of 'as'. The main goal was to ensure
> that a simple strplit would make the job.

I can see your reasoning, but the fact that we're inventing our own
unconventional serialization does concern me, particularly if we plan to
generalize fallback-servers to other protocols and put it in telepathy-spec.

Given that the purpose of the fallback list is to hard-code a list of fallbacks
into application data (a .profile or similar) for particular providers (GTalk
and friends) for the benefit of networks where SRV doesn't work, I don't see
why we'd ever want IP literals, either v4 or v6. It'd be considered rather rude
to hard-code IP addresses into a Google Talk profile shipped with either
Empathy or the N900, for instance. Instead, in practice we'll always be
embedding DNS names that can be looked up with A or AAAA queries.

The only case I can think of where it might be acceptable (or necessary) to use
IP literals is to connect to a server on an intranet, or another server
controlled by the client's organization; in either case, we'd be using the
'server' parameter (which is the only one that should appear in a UI, IMO),
rather than fallback-servers.

(For what it's worth, MC can deal with semicolons in 'as' members - I'm pretty
sure it can escape and unescape them correctly according to the .desktop spec,
and if it doesn't then that's a bug. Semicolons wouldn't really be any better
than commas in this case, though.)

> > Are we ever likely to want to fall back to old-SSL on a port that is neither
> > 5223 nor 443, or normal XMPP on port 5223 or 443? If not, we could perhaps
> > decide whether to use old-SSL based on the port number?
> 
> In my opinion, the cost of being flexible is very low, so why not ?  Also, port
> number is very weak heuristic for old-SSL. Like any server, you are free to run
> it on the port you want.

The cost of being flexible, in this case, is that we go beyond a common
convention into our own ad-hoc mini-language, which isn't ideal, but if it's
necessary I can live with it.

> XMPP might be used as intranet communication, in which
> case we may want to use different port for technical reason.

Empathy/Maemo/whatever isn't going to ship a .profile for a particular
intranet, and if the intranet's owner provides a .profile they can just set a
default 'server' if they need to, so fallback-servers doesn't really seem
relevant in this case?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.