Re: [PATCH] Added basic file system watching support.

[Eli Zaretskii]

> From: Michael Albinus <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden
> Date: Tue, 11 Dec 2012 09:44:55 +0100
> 
> Eli Zaretskii <address@hidden> writes:
> 
> > Then Tramp could maintain its own data structure for watched files,
> > and give each watch a unique identifier, like (FILENAME . NUMBER), or
> > just NUMBER, or whatever.
> 
> That I do already in my inotify-add-watch handler. Of course.
> 
> > IOW, the DESCRIPTOR is an opaque data type, which the implementation
> > back-end, and the back-end alone, can and should interpret.
> 
> The point is, that something must trigger Tramp. In inotify-add-watch, I
> have added the following code (shortened, there's more):

Sorry, I misunderstood the issue.  See below.

> --8<---------------cut here---------------start------------->8---
>   /* If the file name has special constructs in it,
>      call the corresponding file handler.  */
>   handler = Ffind_file_name_handler (file_name, Qinotify_add_watch);
>   if (!NILP (handler))
>     {
>       return call4 (handler, Qinotify_add_watch, file_name, aspect,
>      callback);
>     }
> --8<---------------cut here---------------end--------------->8---
> 
> In inotify-rm-watch I couldn't add similar lines, because file_name is
> unknown. My proposal is either to add file_name as first argument of
> inotify-rm-watch, or to declare WATCH-DESCRIPTOR as a cons cell, which
> car is always the file name.

IMO, this design is wrong.  Tramp is just one more back-end for this
feature, in addition to two others: inotify and w32notify.  So I think
Tramp handlers should be called from a higher-level code, one that
calls whichever back-end is appropriate.  Otherwise, we will need to
implement the Tramp support twice, in 2 different sets of primitives.

Which, of course, goes back to the kind of design discussion I
suggested to have at the time, where we were supposed to consider
various alternatives and eventually agree on some higher-level APIs.
Jumping to coding right away is IMO not the right way.  E.g.,
currently there are subtle but very real differences between the 2
back-ends: w32notify doesn't accept t or a lone symbol as the 2nd
argument (it insists on getting a list); the list of supported watch
types is entirely different; and the w32 back-ends actually watches
the entire directory of the file, not just that file.

IOW, this feature is not really ready for Tramp-ization, or for
user-land in general.  Stefan wanted people to experiment with this
and gather experience, before we know enough to discuss how to make it
user- and Lisp-friendly.