Tcl application deployment
From: Victor Wagner (vitus_at_45.free.net)
Date: 08/23/04
- Next message: Andreas Leitgeb: "Re: Regular expression with 0 or 1 matches option"
- Previous message: Andres Garcia: "Re: Creating event sources"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 23 Aug 2004 07:54:42 +0000 (UTC)
Now there are two main ways to deploy Tcl/Tk application
1. Provide user with bunch of script and dynamic library files
(possibly using some installer or package manager to simplify
installation)
2. Pack everything into one big fat executable using
starkit, prowrap or freewrap.
Both ways has some flaws. Flaws of first way are evident and I wouldn't
stop on them.
Flaws of second way are following:
1. Each application to be installed on user machine has to bring its own
Tcl interpretator and any packages it uses.
2. As far as I know, no OS provides way to load dynamic libraries using
tcl vfs or any other way to load them directly from starkit/zip archive.
So, compiled code have to be extracted into temporary files.
This pose security threat. On typical muliuser system binary code is
stored in the files, writable only by system administrator. This
provides some protection from virus propagation, trojans etc. Attempt to
use temprary files for binary code defeats this protection. Although
trojan should be very clever to exploit temporary files, this is
theoretically possible.
3. There is no way to fix bugs in some package used by application,
short of upgrade entire application. But one of biggest advantages of
dynamic loading is that if bug found in, say zlib, you upgrade just zlib
and ALL apps using it are fixed.
4. There is no ready-to use wrap package which supports Cyrillic
encodings. Of course, it can be solved by careful hacking of freewrap
sources, but if we are starting to hack, why not fix some other problem
same time.
So, I'm thinking of system which combines advantages of both approaches.
First of all, all script files which come with application should be
hidden inside some single file. Probably it should be same file which
user runs to launch application.
Second, tcl interpreter shared library should be placed into file system
as separate file, and so should be other compiled package.
There is problem with packages which include both scripts and compiled
code. For now I think that easy upgradability is more important than
source hiding, so I put script libraries onto the file system intact.
Just now I use no closed source 3rd-party packages, so there is no point
to wrap their sources.
So, everything is needed for this approach is a modified wish
executable, which checks for some kind of arhive (metakit, zip, tar) at
the end of its own file (thanks to Tcl_FindExecutable, it is easy to
locate this file) and if found, mounts it using tcl_vfs and sets startup
script to, say, mounted_archive/main.tcl
This all can easily be done from customized appinit procedure (although
I've to fix zipvfs to allow mounting an archive with executable
prepended)
int myAppInit(Tcl_Interp *interp) {
if (Tcl_Init(interp) == TCL_ERROR) {
return TCL_ERROR;
}
if (Tcl_PkgRequire(interp,"Tk","8.4",0) == TCL_ERROR) {
return TCL_ERROR;
}
Tcl_StaticPackage(interp, "Tk", Tk_Init, Tk_SafeInit);
if (Tcl_PkgRequire(interp,"vfs::zip","1.0",0)==NULL) return TCL_ERROR;
if (Tcl_Eval(interp,"vfs::zip::Mount [info nameofexecutable] zipcode\n"
"lappend auto_path zipcode")!=TCL_OK) return TCL_ERROR;
TclSetStartupScriptPath(Tcl_NewStringObj("zipcode/main.tcl",-1));
return TCL_OK;
}
This is preliminary version. It assumes that startup file is linked with
Tcl library (althouth uses Tcl package mechanism to find Tk library).
I think that such startup file should use some own mechanism to find Tcl library, and load it with dlopen/LoadLibrary.
Really only symbol, which it have to import implicitely is Tcl_Main. Anything else can be accessed via stubs. On Windows Registry can be used to find Tcl installation. On Unix some config file or environment variable could be used to override standard location.
Second stage is to allow script-only packages to be distributed as
single archive files. It seems that pkgIndex.tcl syntax is flexible
enough to allow it. Just change command to load an extension from single
source command to couple of commands - vfs mount + source.
Third stage is to handle combined - script+shared library extensions as
single file - shared library + attached script archive.
--
- Next message: Andreas Leitgeb: "Re: Regular expression with 0 or 1 matches option"
- Previous message: Andres Garcia: "Re: Creating event sources"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
