TIP #10000: Dummy Proposal for Testing Editing Interfaces

TIP:	10000
Title:	Dummy Proposal for Testing Editing Interfaces
Version:	$Revision: 1.202 $
Authors:	Don Porter <dgp at users dot sourceforge dot net> Andreas Kupries <a dot kupries at westend dot com> Richard Suchenwirth <richard dot suchenwirth at kst dot siemens dot de> Kevin B KENNY <kennykb at acm dot org> Jeff Hobbs <hobbs at users dot sourceforge dot net> Vince Darley <vincentdarley at users dot sourceforge dot net> Fabrice Pardo <Fabrice dot Pardo at l2m dot cnrs dot fr> Joe Mistachkin <joe at mistachkin dot com> Donal K. Fellows <donal dot k dot fellows at manchester dot ac dot uk> Mark Janssen <mpc dot janssen at gmail dot com> Reinhard Max <max at tclers dot tk> Andreas Leitgeb <avl at logic dot at>
State:	Draft
Type:	Informative
Vote:	Pending
Created:	Sunday, 03 December 2000

Please enter your e-mail address (required), your name (optional), make your edits to this TIP and its Abstract, and Submit them. See TIP 3 for a description of the TIP format.

You are advised to copy the text of the TIP into an editor, make your edits there, and then paste back.

E-mail:
Name:

Abstract:	This proposal has no content. It exists only to provide a document on which testing of and practice using of the TIP editing interfaces can take place.
Body:	This TIP proposes to add capabilities for monitoring changes in the file system to the Tcl core. like ''scan %'', writing "current position" to a parameter ~ Rationale Most if not all platforms supported by Tcl today allow user space processes to monitor the file system for certain changes such as the creation, deletion, alteration or renaming of files. Unfortunately there is no unique cross-platform API for this, so a Tcl core feature will have to be backed by a series of platform-dependent implementations and possibly a fallback for platforms that don't have these monitoring capabilities or instances on which they have been disabled. Platform-speciffic APIs which should be supported by the final implementation (list to be extended): inotify[http://en.wikipedia.org/wiki/Inotify] (Linux) * kqueue[http://en.wikipedia.org/wiki/Kqueue] (BSD) * FSEvents[http://en.wikipedia.org/wiki/FSEvents] (Mac OS X) * (Windows?) ~ Proposal A new subcommand should get added to the '''file''' command with the following syntax: > '''file monitor''' ''path'' ''callback'' ?''filter''? This will register ''callback'' to be called from the event loop when one of the events specified by ''filter'' occurs to the file or directory specified by ''path''. Calling '''file monitor''' with an empty callback argument removes an existing callback from the given path. The calling conventions for ''callback'' and the syntax of ''filter'' are yet to be determined. ~ Rejected alternatives The '''file''' command was chosen over '''fileevent''' and '''chan event''', because the object to be monitored is passed by name and not as an open channel. As an API, FAM[http://en.wikipedia.org/wiki/File_alteration_monitor] would have been a more portable alternative, but it requres a daemon to be running on the local machine and it requires linking against a lib that is licensed under the LGPL. It might be possible to support FAM as a compile time alternative to the system's native notification method. There exists a serverless implementation of a subset of the FAM API, called Gamin[http://people.gnome.org/~veillard/gamin/index.html], but that's also licensed under the LGPL. There exists a Tcl extension for inotify[https://sourceforge.net/projects/tcl-inotify/], but it is licensed under the GPL and it's script level API is too close to the inotify primitives to serve as the basis of a cross-platform abstraction for such notifications. But it might be a good base for a scripted prototype to sort out the remaining details of the proposed script level API. ~ Further ideas It might be an option to release the C code that unifies the various OS speciffic mechanisms under a single API as a separate library, so that projects other than Tcl can use it as well. ~ Copyright This document has been placed in the public domain.
Log:	This is a supplement to the main log message to allow you to add extra notes if you wish.

Note that when you submit this form, the server will attempt to store your personal details (i.e. name and email address) as cookies in your browser so that next time you edit a TIP, you do not need to retype this info. We do not retain the information on our server (other than as logged in the TIP itself and in the CVS log) and you can delete it without ill-effect if you wish. You are invited to study the implementation code if you wish to understand exactly how the information is stored in your browser.

TIP AutoGenerator - written by Donal K. Fellows