Re: [GnomeMeeting-devel-list] [Fwd: Re: URL bugs?]

[Christian Rose <menthos gnome org>]

mån 2003-06-02 klockan 10.51 skrev Damien Sandras:
> > > It is indeed counter-intuitive... Imagine that to call 
> > > mymachine.com:1740, you have to write :
> > > - callto:mymachine.com:1740
> > > - OR h323:@mymachine.com:1740
> > > 
> > > The @ is the counter-intuitive part, no?
> >
> > Ummm, shouldn't the right thing be:
> > h323://mycachine.com:1740 ?
> 
> Unfortunately not if you follow the RFC, that is why I mailed the first
> time and that is why I told it was counter-intuitive :(
> The RFC:
> http://community.roxen.com/developers/idocs/rfc/rfc3508.html
> 
> Tells that :
> address     =   user / "@" hostport / user "@" hostport
> 
> However, when Robert tells that mymachine.com would be an user name and
> 1740 a password, I'm not sure he is right.

This seems to be the fundamental cause for all the problems mentioned in
this thread. While URL:s are never "intuitive" as a concept and it is
wrong to speak of "intuitiveness" that way, the concepts of an URL
scheme can indeed get familiar to technical people after much usage.

So since the RFC proposes an URL scheme that breaks the expectations for
most people who have ever gotten accustomed to an URL scheme at all,
namely the one used on the rest of the net, the proposal seems to be
severely flawed in this area. It seems the writers of this RFC paid much
time to invent a precise syntax from scratch, but missed the parts with
aiding the use of existing URL parsers and important compatibility with
the most commonly used URL scheme.

Ideally, URL:s should never have to be displayed in a UI. That's a view
shared by most people knowledgeable about usability, in my experience.
They are nothing but a very technical notation for expressing an
abstract thing, and as such really shouldn't be used in UI:s. So seen
from that point of view, perhaps the RFC authors were right in that they
certainly didn't help that use.

However, URL:s often do have some advantages such as easy access and
manipulation, and also display easily spottable and important
information for those who have learned the syntax. So in the case of web
browsers and applications like GM, they typically do make some kind of
sense to have (and IIRC the use of a location field in GM has been
debated before, no need to start that debate again).

But since the primary use of the URL field is to help users with some
previous URL knowledge, rather than being a demonstration of brand new
technical syntax for its own sake, I suggest that GM uses an URL scheme
that resembles the HTTP/FTP URL scheme:

	h323://[username[:password] ]hostname[:port]

This would be displayed and used in the interface *instead* of the
RFC-proposed URL scheme.
This should bring familiarity for those already used to HTTP/FTP URL:s,
and should also help once GM supports multiple protocols in addition to
H323, for example SIP. Then we can still use the same URL scheme and be
consistent with ourselves in GM.

So, GM could work like this:

1. User enters "foo:1740"
2. GM interprets this as an attempt for a H323 connection (if h323 is
the default protocol), and rewrites the URL in the field to
"h323://foo:1740", and tries to connect with H323.
3. If that attempt fails, ask the user if he wants to try SIP instead
(if SIP is the second protocol), or cancel the connection attempt. If
yes, rewrite to "sip://foo:1740" and try connecting using SIP.

This is all very sketchy and I don't know if it makes sense, I have
basically no knowledge of the protocols involved, but I'm just trying to
show that using a consistent, protocol independant and potentially
already familiar URL scheme has its advantages.


Christian