[elpa] externals/cpio-mode 1db3177 07/28: Paring down to the bare application.

[Stefan Monnier]

branch: externals/cpio-mode
commit 1db317766a0bd64cd068bd547d9cf34d31a47e9d
Author: dlewan <d.lewan2000@gmail.com>
Commit: GitHub <noreply@github.com>

    Paring down to the bare application.
---
 DESIGN | 162 -----------------------------------------------------------------
 1 file changed, 162 deletions(-)

diff --git a/DESIGN b/DESIGN
deleted file mode 100644
index 63a2cd9..0000000
--- a/DESIGN
+++ /dev/null
@@ -1,162 +0,0 @@
-#      $Id: DESIGN,v 1.9 2019/01/07 07:44:33 doug Exp $        
-
-# 
-# Copyright © 2019 Free Software Foundation, Inc.
-# 
-# All rights reserved.
-# 
-# This program is free software: you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation, either version 3 of the License, or
-# (at your option) any later version.
-# 
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-# 
-# You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
-# 
-
-A cpio entry basically looks like 
-an inode followed by contents of the specified length.
-Hereafter I'll use the term /entry header/ to refer
-to that inode-like information.
-
-The exact form of the entry header can, unfortunately, vary.
-(Such are the woes of an operating system
-that had friends who didn't play nicely
-[until competition showed up].
-[Gee, that seems like a familiar story, doesn't it?])
-
-According to the documentation for cpio(1GNU)
-there are the following entry header formats:
-• bin,         the obsolete binary format.
-• newc,                the new (SVR4) portable format.
-• odc,         the old portable (ASCII) format.
-• crc,         the new (SVR4) portable format with checksum.
-• tar,         the old tar format.
-• ustar,       the POSIX.1 tar format.
-• hpbin,       the obsolete binary format used by HPUX's cpio.
-• hpodc,       the portable format used by HPUX's cpio.
-
-The file cpio-mode.el is the door into the package.
-cpio-mode.el controls loading other files as needed and, as of yet,
-implements the high-level presentation and user-interface functions.
-
-Believing in portability, the formats newc, odc and crc will be first
-to be implemented.
-tar and ustar formats are already handled by tar-mode and will not be 
implemented.
-If either HP format is implemented, then hpodc will be implemented first.
-
-For common parsing, interpreting, constructing and modifying functions,
-for the different entry header formats (common function, not common 
implementation)
-there will be a common API and implementations done
-in each of the separate files cpio-ENTRY-HEADER-FORMAT.el, e.g. cpio-newc.el.
-
-This will thus have lots of different functions for each entry header format,
-each function named to identify the header format to which it applies.
-In the spirit of lisp, they will be referenced by buffer local variables.
-
-Having done no development whatsoever so far, I'm guessing
-that a generic entry header format will be useful,
-produced, ideally by a single function,
-but, given the variety of formats, cannot be.
-There will therefore be a variety of entry-header-parsing functions, e.g.:
-    cpio-parse-entry-header-bin
-    cpio-parse-entry-header-newc
-    cpio-parse-entry-header-odc
-    cpio-parse-entry-header-crc
-    cpio-parse-entry-header-hpbin
-    cpio-parse-entry-header-hpodc
-, but the common point for programming that /uses/ those functions would be
-to call (funcall cpio-parse-entry-header-func).
-Indeed, the common function (to isolate such cruft even further)
-might be written so simply:
-(defun cpio-parse-entry-header (header-str)
-   "Parse the given HEADER-STRing and return a cpio entry header structure."
-   (funcall cpio-parse-entry-header-func))
-
-Of course, such simplicity is not entirely possible.
-You have to guarantee that cpio-parse-entry-header-func has been
-appropriately populated.
-
-Similarly, a number of variables will exist to reflect differences
-between the different header formats.
-
-################################################################
-Here are some functions that I know this must deliver:
-
-    • presentation (a là dired)
-    • view/edit entry
-    • delete entry
-    • insert entry (If I recall cpio sorts the entries by name,
-                   so this should be unambiguous.)
-    • update entry (after editing.)
-    • create archive (from a list of files, etc. From dired? From what else?)
-    • extract archive (Lots of error handling here.
-    • batch mode operation
-
-Here are some that would also be nice:
-
-    • validate archive
-    • repair archive
-
-Those then reveal at least some support functions:
-
-    • discern archive type
-      * hpbin
-      * hpodc
-      * DONE newc
-      * odc
-      * tar
-      * ustar
-    • parse entry headers
-      * hpbin
-      * hpodc
-      * DONE newc
-      * odc
-      * tar
-      * ustar
-    • DONE find entry contents (cpio-contents)
-    • write entry headers (+ contents)
-      * hpbin
-      * hpodc
-      * DONE newc
-      * odc
-      * tar
-      * ustar
-    • DONE mtime → human date/time conversion (mtime-to-touch-string, 
cpio-mtime-to-mtime-string)
-    • DONE mtime replacement in an entry header structure (cpio-set-mtime)
-      Also other entry-related information.
-      Attributes:
-         * (cpio-set-entry-size)
-         * (cpio-set-entry-name)
-         * (cpio-set-uid)
-         * (cpio-set-gid)
-         * (cpio-set-mode
-      Location information:
-         * cpio-set-header-start
-         * cpio-set-contents-start
-    • DONE uid/gid → string (defcustom cpio-try-names)
-    • DONE octal mode ↔ drwx (s, S, etc.) mode conversions. 
(cpio-int-mode-to-mode-string)
-    • DONE And its inverse (cpio-mode-string-to-int-mode)
-    • dev and rdev handling (No, I have no idea what to do with this right 
now.)
-
-
-All of those functions should have generic implementations.
-They may have header-type-specific get/put functions,
-but the processing itself as above should be generic.
-
-I should read through the info for cpio to see what else might be worthwhile.
-I see things among the options to cpio(1GNU) like these
-    • swap bytes/half words
-    • block size (This will affect padding.)
-    • make-directories
-    • patterns to define which files to include.
-    • link (hard link, common inode number)
-    • dereference
-    • mod time handling
-    • override owner/group 
-    • unconditional overwriting