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