gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] proposal : ~/.authinfo


From: Matthieu Moy
Subject: Re: [Gnu-arch-users] proposal : ~/.authinfo
Date: Thu, 11 Mar 2004 08:02:01 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)

Tom Lord <address@hidden> writes:

>     > Should I implement  it on tla 1.2  or do you suggest I  upgrade to the
>     > latest development version for that ? 
>
> Branch off of the recently created 1.3 line, please.

Ah, too late  ;-) I've already posted the modified  file, based on tla
1.2 :-(

As the ML has problems, here it is again :

http://www-verimag.imag.fr/~moy/vrac/pfs-dav.c

> I'm not so sure that "machine/login/password" is the right idea.
> Shouldn't that be, instead, something more flexible and generic like:
>
>
>     url "http://%s:address@hidden/"; YOURUSERNAMEHERE YOURPASSWORDHERE

Hmm, ~/.authinfo is shared  between many applications (many mailers or
newsreaders for  example use this  convention. This includes  at least
slrn, Gnus), so, introducing a new syntax may break the existing.

I have  no objection  if someone wants  to implement an  arch specific
mechanism in addition to this. We could have a ~/.arch-params/authinfo
file  following  your  suggestion  for  example.  But  I  still  think
implementing the traditional ~/.authinfo is a good thing.

> and then you can register an archive with something like:
>
>
>     tla register-archive $ARCHIVENAME http://%s:address@hidden/$PATH

Yes,  this is  something that  could  be added.  Currently, you  don't
specify user  and password for  the archive registration, and  have to
edit your ~/.authinfo manually.

> Finally, "~/.authinfo" is an ambitiously generic name.

This is what it's made for ;-) (cf. above).

> It'd be swell to write up a little formal spec of this functionality
> and  to publish it  as an  arch-independent library  with absolutely
> minimal dependencies. 

I was surprised  not to find this already, but in  the sources of slrn
I've looked at,  for example, they just have ad  hoc code, with global
variables and all, so I thought  it was simpler to re-write it instead
of reusing it.

But my code has almost no dependancies, so it's really reusable.

-- 
Matthieu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]