source: trunk/third/gnome-vfs2/TODO @ 20794

Revision 20794, 4.0 KB checked in by ghudson, 20 years ago (diff)
This commit was generated by cvs2svn to compensate for changes in r20793, which included commits to RCS files with non-trunk default branches.
Line 
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
17This TODO attempts to cover the larger changes that we
18might want in a GnomeVFS 2.0 release accompanying GNOME 2.0.
19Specific details on bugs, fixes, features should be found
20in GNOME bugzilla, this is just intended to serve as a
21roadmap of larger work-chunks.
22
23Pretty much everything here is tenatively an "it would be nice"
24sort of feature or change. We should highlight any changes
25that 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
78Items from an older TODO. I've removed a bunch of outdated items already,
79but 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
89stuff (Wayne Roberts <wroberts@pwav.com>).
90
91* Add some kind of conversation function, so that e.g. we can know
92what step the op is performing.  (E.g for `open()': "connecting to
93ftp.some.site.net", "logging in", "getting dir listing", "retrieving
94file.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
101cancelled.  We need to be able to send signals to the helper
102threads/processes.
103
104API issues
105----------
106
107* Better hiding of private stuff.
108
109* We definitely need an `URI context', which is basically a URI prefix
110which is used for subsequent calls.  When creating a context, backends
111can assume they are going to get several requests for sub-URIs
112starting from that URI, and can try to optimize things.  OR maybe we
113can just have a function to "lock" a certain URI.  This will make
114everything 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
121Installation issues
122-------------------
123
124* We need to install the private headers: otherwise, it is not
125possible to write new modules without the full gnome-vfs source code.
126Maybe we need to have more than two levels (i.e. more than just
127"private" and "public" headers).
Note: See TracBrowser for help on using the repository browser.