[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Added basic file system watching support.
From: |
Eli Zaretskii |
Subject: |
Re: [PATCH] Added basic file system watching support. |
Date: |
Tue, 11 Dec 2012 11:39:15 +0200 |
> 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.
- Re: [PATCH] Added basic file system watching support., Michael Albinus, 2012/12/11
- Re: [PATCH] Added basic file system watching support., Eli Zaretskii, 2012/12/11
- Re: [PATCH] Added basic file system watching support., Michael Albinus, 2012/12/11
- Re: [PATCH] Added basic file system watching support., Michael Albinus, 2012/12/11
- Re: [PATCH] Added basic file system watching support., Eli Zaretskii, 2012/12/11
- Re: [PATCH] Added basic file system watching support., Michael Albinus, 2012/12/11
- Re: [PATCH] Added basic file system watching support., Eli Zaretskii, 2012/12/11
- Re: [PATCH] Added basic file system watching support., Leo, 2012/12/11
- Re: [PATCH] Added basic file system watching support., Eli Zaretskii, 2012/12/11