From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/66041 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.tramp,gmane.emacs.gnus.general Subject: Re: file storage in IMAP (eventually for Tramp) working and needs testing Date: Fri, 04 Jan 2008 12:00:08 +0100 Message-ID: References: <86k5n1443g.fsf@lifelogs.com> <87fxxjgohd.fsf@gmx.de> <873atjgf6m.fsf@gmx.de> <86r6h2x6fv.fsf@lifelogs.com> <87y7bag519.fsf@gmx.de> <86ejd2wyej.fsf@lifelogs.com> <87odc6ft4e.fsf@gmx.de> <86myroyn3v.fsf@lifelogs.com> <877iir4win.fsf@gmx.de> <86prwjxcwp.fsf@lifelogs.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199444377 11030 80.91.229.2 (4 Jan 2008 10:59:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Jan 2008 10:59:37 +0000 (UTC) Cc: Tramp Development List , ding@gnus.org To: Ted Zlatanov Original-X-From: tramp-devel-bounces+tramp=quimby.gnus.org@gnu.org Fri Jan 04 10:59:35 2008 Return-path: Envelope-to: tramp@deer.gmane.org Original-Received: from quimby.gnus.org ([80.91.231.51]) by ciao.gmane.org with esmtp (Exim 4.43) id 1JAkGz-0001GJ-Cj for tramp@deer.gmane.org; Fri, 04 Jan 2008 10:59:33 +0000 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1JAkH0-00010v-00 for ; Fri, 04 Jan 2008 11:59:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAkGy-0004SZ-CX for tramp@quimby.gnus.org; Fri, 04 Jan 2008 05:59:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JAkGs-0004QX-NM for tramp-devel@gnu.org; Fri, 04 Jan 2008 05:59:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JAkGr-0004OP-EN for tramp-devel@gnu.org; Fri, 04 Jan 2008 05:59:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAkGr-0004Nw-7h for tramp-devel@gnu.org; Fri, 04 Jan 2008 05:59:25 -0500 Original-Received: from mailrelay1.alcatel.de ([194.113.59.95]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JAkGq-000559-Q0 for tramp-devel@gnu.org; Fri, 04 Jan 2008 05:59:25 -0500 Original-Received: from slbhab.alcatel.de (slbhab.bln.sel.alcatel.de [149.204.63.218]) by mailrelay1.alcatel.de (8.13.4/8.13.4/ICT) with ESMTP id m04AwwWI000682; Fri, 4 Jan 2008 11:58:58 +0100 In-Reply-To: <86prwjxcwp.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu, 03 Jan 2008 07:21:42 -0600") User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (hpux) X-Scanned-By: MIMEDefang 2.51 on 149.204.45.72 X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: tramp-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: tramp-devel.gnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: tramp-devel-bounces+tramp=quimby.gnus.org@gnu.org Errors-To: tramp-devel-bounces+tramp=quimby.gnus.org@gnu.org Xref: news.gmane.org gmane.emacs.tramp:6422 gmane.emacs.gnus.general:66041 Archived-At: Ted Zlatanov writes: > Say you have these article UIDs and subjects, and UIDs are ordered by > date. Note the ENCODED_FILENAME will be the filename encoded in some > way and /a/b/c is the filename without any risky characters; Gnus has > the subject encoding functionality already. The subject format is > specifically to allow easy searching. > > 1 "tramp-imap-marker /a/b/c ENCODED_ABC" > 2 "tramp-imap-marker /a/b/c ENCODED_ABC" > 3 "tramp-imap-marker /a/b/c ENCODED_ABC" > 4 "hello world" > > Do we > > A) allow for three identically named files, dynamically renaming 2 and 3 > with the Emacs <1> and <2> convention? > > B) ignore 1 and 2, never create them intentionally, and (optionally) > erase duplicates when a file is saved? This is probably easiest to > implement in code. > > C) treat 1 and 2 as backups (there will be a tramp-imap-backups > parameter to control how many are allowed per filename, and older ones > over that limit are erased when a file is saved)? We'll need a > mechanism to revert to a backup, which I don't think Tramp has built-in > at the moment. If 1, 2 and 3 are created only by tramp-imap, then C might be the preferred choice. B doesn't look good to me, I believe all files must be accessible. > Second question: is message 4 ignored? I would prefer to do so, to > allow coexistence of tramp-imap.el with other messages (or even later > versions of tramp-imap.el). Maybe. But then tramp-imap would only access files it has created itself, this might be a restriction. Of course it wouldn't be good if tramp-imap would change subject lines of existing messages. Do we need to encode the filename in the subject line? Couldn't it be any other header, like X-Tramp-Filename? > Third question: namespaces. I feel that it's much better > for the user to store all the files in a single mailbox: [...] Honestly, I'm not so familar with IMAP conventions. I have no precedence for this, you might decide yourself. > Here's the list (omitting the commented-out items from tramp-smb.el) > with some questions and comments. Sorry if most of this is obvious, > this is my first time diving into the Tramp code. What function would > handle the truename-to-visualname translation? There is an "atomic" function tramp-smb-send-command, which makes the communication with the server. Similar functions are tramp-send-command and tramp-send-fish-command in their respective packages. I guess you'll need a tramp-imap-send-command or so; this could be a central place for the mapping. Other places might be needed as well when *interpreting* the result of a sent command. [...] > add-name-to-file: could be a special "link message" or just a copy, like in Windows Both is possible. Btw, on my todo is implementing a real link for Windows, but this has no priority. > copy-file: implemented as an APPEND > delete-directory: implemented with a search+delete for all matching messages OK. > delete-file: search+delete of all matching messages It depends how we decide with your first question. If there is uniqueness in mapping file names to true names, than there is only one message to be deleted. > directory-file-name: tramp-handle-directory-file-name? > directory-files: search for matches OK. > directory-files-and-attributes: search for matches, attributes always 777 It returns more than just file permissions. > dired-call-process: ignore OK. > dired-compress-file: ignore Likely yes, but there might be an implementation depending on how a message is stored. > file-accessible-directory-p: always t No. Use default implementation (which checks both file-directory-p and file-executable-p). > file-attributes: always 777 No. file-attributes returns a list of 12 different attributes. Must be implemented. > file-directory-p: needs a search, but we could have a file name that conflicts with a directory name We shall avoid such conflicts. A file name shall be unique. > file-executable-p: always nil Better is t (see file-accessible-directory-p). It doesn't hurt, because we don't support processes. > file-exists-p: needs a search OK. > file-local-copy: ? That is the basic function for retrieving a file from the server. It stores the file in the temp directory; some other functions use it then (like insert-file-contents etc). > file-remote-p: tramp-handle-file-remote-p OK > file-modes: tramp-handle-file-modes or hard-code Both is possible. tramp-handle-file-modes is shorter to write. > file-name-all-completions: needs a search > file-name-completion: tramp-handle-file-name-completion > file-name-directory: tramp-handle-file-name-directory > file-name-nondirectory: tramp-handle-file-name-nondirectory > file-newer-than-file-p: needs a search, plus backups may matter > file-ownership-preserved-p: ignore OK > file-readable-p: always t > file-regular-p: always t No. You must return nil when the file does not exist. > file-symlink-p: always nil > file-truename: returns UID OK > file-writable-p: always t No, again the case of non existing file names. > find-backup-file-name: we need to decide > insert-directory: ? Both can be postponed, they are not basic functions. > insert-file-contents: search+retrieve file-local-copy and insert-file-contents of that local copy. > load: tramp-handle-load > make-directory, make-directory-internal: we need to decide what this should do > make-symbolic-link: ignore or implement as a special message > rename-file: append with new subject, delete original and its backups if > we decide to do backups > set-file-modes: ignore > set-visited-file-modtime: we could use a header for this OK > shell-command: ignore? Yes > substitute-in-file-name: ? tramp-handle-substitute-in-file-name > unhandled-file-name-directory: tramp-handle-unhandled-file-name-directory? > vc-registered: always nil OK > verify-visited-file-modtime: ? Maybe ignore for the time being, it's not core functionality. > write-region: needs to do an append+delete of original+backups as needed; IMAP can't rewrite a message OK I would start with file-local-copy and write-region, these are the functions for retrieve and store a file. > Thanks > Ted Best regards, Michael.