TODO

   1
   2  GnomeVFS 2.4 TODO (Michael's wishlist)
   3  =================
   4
   5         * backend test / validation framework
   6                 + nail down woolly semantics:
   7                 + if open SEEKABLE, then seek
   8                   shouldn't return 'not supported'
   9                 + consistant error return values for misc.
  10                   methods.
  11                 + URI / name escaping tests.
  12
  13
  14  GnomeVFS 2.0 TODO
  15  =================
  16
  17 This TODO attempts to cover the larger changes that we
  18 might want in a GnomeVFS 2.0 release accompanying GNOME 2.0.
  19 Specific details on bugs, fixes, features should be found
  20 in GNOME bugzilla, this is just intended to serve as a
  21 roadmap of larger work-chunks.
  22
  23 Pretty much everything here is tenatively an "it would be nice"
  24 sort of feature or change. We should highlight any changes
  25 that are really critical.
  26
  27 --GNOME 2.0 platform--
  28
  29   * Communicate with application developers and get feedback
  30     on changes or additions they'd like to see in GnomeVFS APIs.
  31
  32 -----New Features-----
  33
  34   * SSL support, particularly for the HTTP module
  35
  36   * Documentation, documentation documentation. We should gun
  37     for 100% documented status for 2.0.
  38
  39   * gzip, bzip2, tar, etc. Figure out how to properly handle
  40     these and implement it. It would be best if it can be
  41     application transparent.
  42
  43 ----Enchancements-----
  44
  45   * Make the MIME database return the "correct information"
  46     for a file. e.g. user selected icons, handling programs,
  47     actions, etc. This will require the metadata API support.
  48     (this may entail API changes to do it the "best way")
  49
  50 ------New APIs-------
  51
  52   * Add a file metadata API. Adopt some convention
  53     for storing metadata on filesystems without such (almost
  54     all of the currently supported filesystems except WebDAV).
  55     We probably want to use a large chunk of the Nautilus
  56     metadata system for this.
  57
  58   * Add a filesystem event notification API. Write backends for
  59     fam/imon and the Linux Kernel 2.4 directory monitor.
  60
  61   * Add helper functions to solve problems that application
  62     programmers will run into frequently using GnomeVFS. For example,
  63     parsing user input with relative paths and detecting
  64     if they are URIs, URI fragments, plain paths...etc. Much
  65     code of this nature needs to be refactored out of Nautilus.
  66
  67 -------Modules-------
  68
  69   * SMB module (Windows Filesharing)
  70
  71   * CVS module
  72
  73   * SSH module
  74
  75
  76 =======================================================================
  77
  78 Items from an older TODO. I've removed a bunch of outdated items already,
  79 but I suspect even more of these are invalid.
  80
  81      -Seth
  82
  83
  84 * tar method, cpio method.
  85
  86 * GZIP write support might be broken.
  87
  88 * Implement SMB support through Wayne's cool librarified Samba client
  89 stuff (Wayne Roberts <wroberts@pwav.com>).
  90
  91 * Add some kind of conversation function, so that e.g. we can know
  92 what step the op is performing.  (E.g for `open()': "connecting to
  93 ftp.some.site.net", "logging in", "getting dir listing", "retrieving
  94 file.tar", "extracting file.c".)
  95
  96 * Make sure that only one module is initialized at a given time
  97 (i.e. add a lock that must be obtained before calling the
  98 `vfs_module_init()' function).
  99
 100 * Complete cancellation code, to make sure every operation can be
 101 cancelled.  We need to be able to send signals to the helper
 102 threads/processes.
 103
 104 API issues
 105 ----------
 106
 107 * Better hiding of private stuff.
 108
 109 * We definitely need an `URI context', which is basically a URI prefix
 110 which is used for subsequent calls.  When creating a context, backends
 111 can assume they are going to get several requests for sub-URIs
 112 starting from that URI, and can try to optimize things.  OR maybe we
 113 can just have a function to "lock" a certain URI.  This will make
 114 everything easier to implement.
 115
 116 * Make directory/xfer calls cancellable as well.
 117
 118 * Specific issues
 119         gnome_vfs_monitor_callback's info_uri should be const.
 120
 121 Installation issues
 122 -------------------
 123
 124 * We need to install the private headers: otherwise, it is not
 125 possible to write new modules without the full gnome-vfs source code.
 126 Maybe we need to have more than two levels (i.e. more than just
 127 "private" and "public" headers).