Tcl repository name proposals
Don Libes
repository. (I started writing a CGI script from scratch and when I
found myself thinking about how to allow other people to make
comments, I realized NICS was a suitable solution already.) The
address is:
If you want to go directly to the new domain, the direct URL is:
Don
Tom Poindexter
Don Libes <li...@nist.gov> wrote:
>I've set up a page for us to brainstorm on names for the proposed Tcl
>repository. (I started writing a CGI script from scratch and when I
>found myself thinking about how to allow other people to make
>comments, I realized NICS was a suitable solution already.) The
>address is:
Cool, now I can add the 'Cheesy-poofs' entry!
--
Tom Poindexter
tpoi...@nyx.net
http://www.nyx.net/~tpoindex/
Alexandre Ferrieux
>
> I've set up a page for us to brainstorm on names for the proposed Tcl
> repository. (I started writing a CGI script from scratch and when I
> found myself thinking about how to allow other people to make
> comments, I realized NICS was a suitable solution already.)
If you want collaborative work, and (as I do) dislike being nagged by
too much useless structure, why not use the Tclers' Wiki ?
http://purl.org/thecliff/tcl/wiki/
-Alex
Don Libes
Wiki is cool and tremendous potential but for some things (like name
proposals), I don't like it. For instance, I don't like the
possibility that I could be adding things at the same time as someone
else and one of our changes doesn't go through. This is a real
concern in rapidly evolving discussions. I also don't like the idea
that anyone can wipe out anyone else's contribution or can modify
their statements in a way that the original author may not like or ...
It's not really fair to critique NICS about its structure unless you
can specifically say how Wiki can do it better. Wiki's structure has
its own limitations after all (ironically, it's "lack of structure" is
actually mentioned as a problem in the Wiki Gripes page). You can
undoubtedly come up with a proposal, but in the end, it's all a matter
of trade-offs.
Don
lvi...@cas.org
:proposals), I don't like it. For instance, I don't like the
:possibility that I could be adding things at the same time as someone
:else and one of our changes doesn't go through. This is a real
I agree - hopefully this will be addressed once our fearless programmer
returns from holiday... as he was leaving, he dropped some of us an
email stating that he had this great idea for file locking and had installed
the first part of the solution.
:concern in rapidly evolving discussions. I also don't like the idea
:that anyone can wipe out anyone else's contribution or can modify
:their statements in a way that the original author may not like or ...
I very much agree with this last point - so that's why the history feature
is the second highest priority in my mind (followed thirdly by some means
to do site mapping).
--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Alexandre Ferrieux
>
> Wiki is cool and tremendous potential but for some things (like name
> possibility that I could be adding things at the same time as someone
> else and one of our changes doesn't go through. This is a real
Yes, there are still a few things to iron out. We are working on them.
A solution for this one could be that the down-path (from Wiki to
client) includes a 'checkout timestamp', while the up-path ignores it
and uses the date of upload instead. This way, the full anteriority info
is available to do proper version handling, smart mergers, etc.
> I also don't like the idea
> that anyone can wipe out anyone else's contribution or can modify
> their statements in a way that the original author may not like or ...
This is an experimental feature, but I think it has some value. Of
course, some parts are more like a newsgroup, so all you need is a
growing list of messages, with no way to change the past (apart from
maybe Cancel). But other parts are really collaborative work, where a
few people really want to *edit* an otherwise static page. A middle
ground could be to add a pinch of authentication there, and people
wanting to allow others to edit their work would simply communicate them
the auth key... We're open to suggestions !
> It's not really fair to critique NICS about its structure unless you
> can specifically say how Wiki can do it better.
Of course. I'm just saying that *I* dislike too constraining interfaces
while a simple informal white board like Wiki would do. To do this in
Wiki, I'd simply create a page with paragraphs whose titles are the
proposed names so far, the contents of each paragraph being roughly a
discussion thread. (and as you noticed, we'd have to trust people to
behave correctly. For me it's not a problem; I've always believed that
concerns about security statistically do much more harm than real
security attacks...)
> Wiki's structure has
> its own limitations after all (ironically, it's "lack of structure" is
> actually mentioned as a problem in the Wiki Gripes page).
Yes, but in a very specific (and different) context. The gripe was about
the lack of a 'Site Map'.
We are also making progress in that regard right now; expect nes pretty
soon !
> You can
> undoubtedly come up with a proposal, but in the end, it's all a matter
> of trade-offs.
Of course. But we can still compare two different trade-offs, right ?
:-)
-Alex
Don Libes
> > undoubtedly come up with a proposal, but in the end, it's all a matter
> > of trade-offs.
>
> Of course. But we can still compare two different trade-offs, right ?
> :-)
Yes!
By the way - a quick update - there are now proposals for 13 different
names for the repository. Some of them are quite, uhhh, provocative.
Don