Re: login failure on WindowsNT

[rsalz]

The method should be in the URI prefix since it really does identify
the communication protocol.  Save "cvs" for the standard CVS protocol;
cvs-p perhaps for pserver, cvs-ssh for SSH, etc.  The method name does
not belong in the URI body.

Then after the // use the standard URI style:
        user:address@hidden:port
I'm not gonna write the BNF -- here are the rules in prose:
        Either user or password may be omitted and will default to
        some value specific to the remote host. If both are omitted,
        then the initial colon and atsign should also be omitted.

        The port number is optional and defaults to a value dependant
        on the URI prefix.  If present, it must be preceeded by a
        colon and followed by a decimal number.  (Named ports are
        a no-no.)

After the remote server identification comes the "root" of the CVS
repository.

If you need to refer to a specific module, use pound sign, the
module name, and an optional slash and file name.  I don't think
that there is a reasonable way to really use this, but URI fragments
seems clearly the way to spec it.

There are a number of Web-CVS interfaces; snarf their URI syntax for
things like branches, revisions, etc.  *IFF needed.*

Hope this helps.
        /r$

>From rsalz  Thu Oct 12 17:22:27 2000
From: "Derek R. Price" <address@hidden>
Organization: Open Avenue
To: Larry Jones <address@hidden>
CC: address@hidden
Subject: Re: login failure on WindowsNT
Date: Thu, 12 Oct 2000 17:01:26 -0400

Larry Jones wrote:

>     cvs://method/address@hidden:port/cvsroot
>
> has a / in the "server" part, which isn't allowed; I'd suggest :
> instead:

Didn't remember that.  Ok.


>         cvs://method:address@hidden:port/cvsroot

I was hoping to make both 'user' & 'method' optional, so, with an optional port,
and leaving room for named ports, a parser won't easily be able to distinguish
method:host from host:port


> Another possibility would be:
>
>         cvs://:method:address@hidden:port/cvsroot
>
> which looks a little funny, but has the nice property that what comes
> after the // is exactly a CVSROOT specification.

I was thinking this might be the way to go, and it does resolve both the above
problems.  I hadn't thought it through enough yet to realize that it's parsable
and really looks like a pretty standard URL.  I think it'd have to be:

        cvs://[:method:][user[:address@hidden:port]/cvsroot

with '[...]' specifying optional parameters, of course.

Hmm.  Is there a point to this?  The basic use case I can come up with would be
an anonymous user running a checkout by clicking on a link.  Unfortunately, this
URL spec doesn't include a module specification.  This weakness extends to
branches & dates.  The logic here is that any checkout you could specify on the
command line should be specifiable in a URL.

Another weakness seems to be an inability to differentiate between
:ext: methods.  This could maybe be solved by adding an :ssh: method or,
alternately, allowing a method syntax like, :address@hidden:.  A
bit confusing and inextensible, but it should work.

Ok.  Back to use cases:

Without the ability to specify modules, this URL makes sense for a GUI client
such as gCVS and a server with the 'ls' patch to allow browsing.  (i.e. The user
would click the link in a browser, the browser would pass the URL to gCVS, gCVS
would login and allow the user to start browsing available modules.

Without the ability to specify modules, this URL could also trigger only a login
action when clicked.  Then the user would be logged in and it could be left to
them to figure out what else to do.  Easy for us, but the user is still going to
have to retype the URL at some point to initiate their first checkout.  They'd
also have to type a module name.

With extra syntax which provides the ability to specify modules, branches,
& dates, a user could checkout modules, development branches, and releases from
anonymous cvs repositories with a single click.

With extra syntax to specify which rsh-like program to use, I could provide a
link to an anonymous but secure server for a corporate client.

Of course, something that can simply be pasted into CVSROOT seems clean at first
glance, but why define a URL if you can't click on it for effect from a browser
anyhow?  And there seems to be a lot of power in a link that allows a new user
to download the tip of a project's dev or stable branch in a single click.

Comments?  Ideas?  Problems?  More use cases?

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden     OpenAvenue ( http://OpenAvenue.com )
--
Southern DOS: Y'all reckon? (yep/Nope)




_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs