File: TODO

package info (click to toggle)
gnome-vfs 1:2.24.4-6.1
  • links: PTS, VCS
  • area: main
  • in suites: sid, stretch
  • size: 17,144 kB
  • ctags: 10,422
  • sloc: ansic: 78,500; sh: 10,341; makefile: 902; perl: 99
file content (127 lines) | stat: -rw-r--r-- 4,056 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127

 GnomeVFS 2.4 TODO (Michael's wishlist)
 =================

	* backend test / validation framework
		+ nail down woolly semantics:
		+ if open SEEKABLE, then seek
		  shouldn't return 'not supported'
		+ consistant error return values for misc.
		  methods.
		+ URI / name escaping tests.


 GnomeVFS 2.0 TODO
 =================

This TODO attempts to cover the larger changes that we
might want in a GnomeVFS 2.0 release accompanying GNOME 2.0.
Specific details on bugs, fixes, features should be found
in GNOME bugzilla, this is just intended to serve as a
roadmap of larger work-chunks.

Pretty much everything here is tenatively an "it would be nice"
sort of feature or change. We should highlight any changes
that are really critical.

--GNOME 2.0 platform--

  * Communicate with application developers and get feedback
    on changes or additions they'd like to see in GnomeVFS APIs.

-----New Features-----

  * SSL support, particularly for the HTTP module

  * Documentation, documentation documentation. We should gun
    for 100% documented status for 2.0.

  * gzip, bzip2, tar, etc. Figure out how to properly handle
    these and implement it. It would be best if it can be 
    application transparent.

----Enchancements-----

  * Make the MIME database return the "correct information"
    for a file. e.g. user selected icons, handling programs,
    actions, etc. This will require the metadata API support.
    (this may entail API changes to do it the "best way")

------New APIs-------

  * Add a file metadata API. Adopt some convention
    for storing metadata on filesystems without such (almost
    all of the currently supported filesystems except WebDAV).
    We probably want to use a large chunk of the Nautilus
    metadata system for this.

  * Add a filesystem event notification API. Write backends for
    fam/imon and the Linux Kernel 2.4 directory monitor.

  * Add helper functions to solve problems that application
    programmers will run into frequently using GnomeVFS. For example,
    parsing user input with relative paths and detecting
    if they are URIs, URI fragments, plain paths...etc. Much
    code of this nature needs to be refactored out of Nautilus.

-------Modules-------

  * SMB module (Windows Filesharing)

  * CVS module

  * SSH module


=======================================================================

Items from an older TODO. I've removed a bunch of outdated items already,
but I suspect even more of these are invalid.

     -Seth


* tar method, cpio method.

* GZIP write support might be broken.

* Implement SMB support through Wayne's cool librarified Samba client
stuff (Wayne Roberts <wroberts@pwav.com>).

* Add some kind of conversation function, so that e.g. we can know
what step the op is performing.  (E.g for `open()': "connecting to
ftp.some.site.net", "logging in", "getting dir listing", "retrieving
file.tar", "extracting file.c".)

* Make sure that only one module is initialized at a given time
(i.e. add a lock that must be obtained before calling the
`vfs_module_init()' function).

* Complete cancellation code, to make sure every operation can be
cancelled.  We need to be able to send signals to the helper
threads/processes.

API issues
----------

* Better hiding of private stuff.

* We definitely need an `URI context', which is basically a URI prefix
which is used for subsequent calls.  When creating a context, backends
can assume they are going to get several requests for sub-URIs
starting from that URI, and can try to optimize things.  OR maybe we
can just have a function to "lock" a certain URI.  This will make
everything easier to implement.

* Make directory/xfer calls cancellable as well.

* Specific issues
	gnome_vfs_monitor_callback's info_uri should be const.

Installation issues
-------------------

* We need to install the private headers: otherwise, it is not
possible to write new modules without the full gnome-vfs source code.
Maybe we need to have more than two levels (i.e. more than just
"private" and "public" headers).