Re: login failure on WindowsNT

[Derek R. Price]

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)