as a CGI interface to an extension repository.The code behind the prototype CANTCL repository is available via the Sourceforge Project [2] (as well as from CANTCL itself).27 Sept 2002 - CANTCL now supports uploading files and viewing package descriptions via the web interface. To come:- Browse inside package files via the web
- Query interface to packages
- Categorised browsing of packages
- SOAP interface to the repository
January 2009 - CANTCL is pretty much dead but if you want to browse the source or any of the packages that were hosted see http://www.ics.mq.edu.au/~cassidy/tcl/extensions/.The code behind the CGI script is from my installer library discussed in Tcl Based Installers. Some procs are specific to supporting TIP55 style packages:
installer::parse_description file -- parse a DESCRIPTION.txt file installer::validate_package dir -- is this package TIP55 legal? installer::pkginfo zipfile fields -- return some fields from a DESCRIPTION.txt file inside this zipfile installer::index_directory dir ?fields? -- return a list of package and thier info from the zipfiles in dirCANTCL seems to derive from Mac Cody:[3] Comprehensive Archive Network for TCL. A recent discussion mentioned a concern about the name - one might find it is pronounced as "Can't Tcl"Mac Cody - I registered the CANTCL acronym and the two most sensible definitions with the NIST Identifier Collaboration Service on 29 May, 2001. They are viewable through this link [4].According to Mirriam-Webster OnLine, a canticle is one of several liturgical songs (as the Magnificat) taken from the Bible. I find it a rather appropriate name, as a Tcl software archive certainly is music to my ears!I rather liked Donal Fellows's idea: TENET, the Tcl Extension NETwork -- WHDMac Cody - Unfortunately, Tenet is a trademark of Tenet HealthSystem Medical, Inc.
davidw - why not write the description file in Tcl? Tcl already has a parser:-)escargo - How about using YAML for the description file? (10/13/2002)SC - Because it's harder to understand (for humans) than RFC822 format and probably also harder to code the parser. Not that YAML isn't interesting though, although I think the world has enough MLs just now:-)escargo - How does e-mail (RFC822 [5]) apply to this? I don't see the connection. (10/15/2002)SC RFC822 defines the format of email headers:
To: Steve@here.com From: John@there.com Subject: somethingthis is a nice simple way of writing name/value pairs, even including a way of writing long values (with a leading tab on follow on lines). It's easy to write, easy to parse, fun for all the family!
LV I'm all for easy reading and writing, but I'd rather us look at standardizing on some format used in other packaging descriptions if relevant, simply to reduce the number of formats people have to remember.
My motivation was to make the syntax _simpler_ than having it in tcl, the 'parser' for the rfc format is only a few lines of code anyway. CF:
Identity: mypackage Version: 1.0.0with
set pkginfo(identity) {mypackage}
set pkginfo(version) {1.0.0}I'm also concerned about sourcing tcl files even with the checks and controls around tcl safe interpreters. I don't want to entertain the possibility of someone exploiting a safe-tcl bug by uploading a rogue package. You're right about the security issue however - Tcl is powerful, so dangerous in malicious hands... You might remove the exec, file and other commands from the interpreter, and rename exit to something only you can call...RS: But this example is *so* easily done in Tcl, as we are so free in our language:
proc Identity: name {set ::pkginfo(identity) $name}
proc Version: number {set ::pkginfo(version) $number}This way you can write like in the first example, but still let Tcl parse it (and raise errors for missing or excess argument etc.) without us having to do the parsing.For security issues, you might remove the exec and file commands, and rename exit to something only you can call...SC except for the allowed multi-line values:
Description: this is a packages which is terribly terribly
terribly useful to many people.The parser is easier to write than dealing with the issues of having a config file be code. Plus, you can (more easily) give useful error messages, "Malformed Description line" rather than "invalid command name".Look at FreePAN http://www.freepan.org/
May be better to support it, than create something unrepeatable?SC FreePAN seems to be aiming to be a mirrored file repository, CANTCL wants to be a bit more than that since it will support Tcl specific features like delivering packages in alternate formats (zip, starkit) and browsing inside of packages, even remote mounting of packages via vfs.During mid Sept 2003, Steve announced that CANTCL is working again, with new features such as browsing inside stored packages and ability to upload new packages.
escargo 3 Oct 2003 - I was looking at the CANTCL code, but it was not obvious where the tip55 package was defined. I didn't see anything in code directories of cantcl. I didn't see anything in the wiki pages that was an obvious source of the tip55 package. Could you make it more clear for me? Thanks.escargo 12 Apr 2005 - Look here: http://www.tcl.tk/cgi-bin/tct/tip/55.html
SC -- the above url describes the package format supported by CANTCL, the tip55 package, part of the CANTCL implementation, provides some utilities for handling package metadata etc. The code can be found in CVS at the Sourceforge project http://cantcl.sf.net/ It looks like my protoCANTCL is broken at the moment (13 April 05), otherwise you'd be able to browse the code there too.Related pages: ETEN, STEP (SEE, WOBBLE) Tcl Repository Wish List
