Version 29 of Cantcl

Updated 2003-01-31 12:16:07

Speak: Canticle. :)

Steve Cassidy is working on Tclish as the basis a of Tcl extension installer. As a part of that, he has created TIP 55 [L1 ] to discuss a format for code that gets installed. As an outgrowth of this, Steve created http://www.ics.mq.edu.au/~cassidy/cgi-bin/cantcl as a CGI interface to an extension repository.

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

See Package MetaData Fields for a list of the fields available for use in package descriptions according to TIP 55.

The proto-CANTCL has a URL based interface which I'm trying to flesh out in: CANTCL URL interface.


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 dir

CANTCL seems to derive from Mac Cody: [L2 ] Comprehensive Archive Network for TCL. A recent discussion mentioned a concern about the name - one might find it is pronounced as "Can't Tcl"

I rather liked Donal Fellows's idea: TENET, the Tcl Extension NETwork -- WHD


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 [L3 ]) apply to this? I don't see the connection. (10/15/2002)

SC RFC822 defines the format of email headers:

 To: [email protected]
 From: [email protected]
 Subject: something

this 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!


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.0

with

  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".


Related pages: ETEN, STEP (SEE, WOBBLE) Tcl Repository Wish List, Category Application