FTP requires that the frontend parse html-indexed-format. Currently, mozilla has a directory viewer which handles this format. It creates a RDF tree displayed in xul. For embedding, this may not be possible due to memory footprint issues. FTP should optionally return the listing as html. What is required is a new stream convert which can translate the html-indexed-format to html as well as a pref which toggle which format is returned by the ftp channel.

With this patch, and adding this pref "network.ftp.generate_html", ftp will generate html. This allows embedders to ship without rdf, xul, chrome, and will view FTP sites. It also allows quick isolation of problems between the directory viewer (eg. the tree widget that you normally see) and the ftp protocol. Jud/Gagan can one of you review please?

The patch doesn't apply on linux (RH7) -- patch doesn't understand the syntax used to create the new files, and gets confused by the Makefile.in patch as well. After I applied those parts of the patch by hand, it doesn't compile: nsIndexedToHTML.cpp: In method `nsresult nsIndexedToHTML::OnStartRequest (nsIRequest *, nsISupports *)': nsIndexedToHTML.cpp:61: `buffer' undeclared (first use this function) Looks like the line where buffer should be declared got deleted somehow.

I'm hoping this will give a workaround for bug 70258 (ftp doesn't work at all) and for bug 12707 (the inability to go "up" a level since the directory listing omits the .. and doesn't replace it with anything).

nice! once these are compiling, I'd love to review. at first glance this looks great.

Just looking at the patch: network.dir.generate_html, instead? (Parsing the gopher output would require copy-and-pasting from nsDirectoryViewer.cpp - maybe this could go there, somehow, and share the parsing code. I could possibly do that at some point) Handle201 calls nsUnescape before PL_strchr, but the buffer may refer to files with embedded spaces (and won't the last-modified always have spaces in it?) Won't this also break non-ASCII files? Everything is passed arround as ascii, then .AppendWithConversion'd back into an nsString.

maybe the check could be if (XUL directory viewer doesn't exist) then use html?

I checked in the nsIndexedToHtml files into cvs. Also attached is the diff to enable it on unix. I have incorporated all suggestions, but I still need a r= One thing to note, is that this is a rough cut of a Indexed to HTML converter. We are only handling the 201 state. Any other states that are needed will come is as bugs.

whoops missed something before. You're doing the chaining of stream converters by hand. There's a ton of code to do the chaining from type A to type X behind the scenes. Ray broke this code w/ his contract id landing several months ago (ray, any chance of you coming out of the woodwork to fix it?). I spent a lot of time building that breadth first search algorithm to do it and I'll be damned if we're not going to use it. Doug, did you have a chance to see how it broke and what a possible fix was?

This patch doesn't solve bug 70258 -- I still get the blue screen with the patch applied and user_pref("network.ftp.generate_html", true) in user.js.

wierd akkana. I will drop by tomorrow to take a look at 70258. I got a r= valeski this morning via the telephone. Mscott can I get a sr=?

Fix checked in. Give it a try today! :-)

Can't get it to work on Linux build 2001030621, I've tried setting the pref("network.ftp.generate_html", true); in all.js without success and then tried user_pref("network.ftp.generate_html", true); in my profiles prefs.js also with no success. I check to make sure that there was no other pref setting this value to false. Expected result: Get an HTML based directory listing Actual result: Get the XUL based directory listing

Did the same thing as David Hallowell, set both pref and user_pref in the all.js file, using the 2001030605 build (win32 installer). FTP directories show only as XUL (eg., as before), not HTML.

really? can you try with a new profile?

OK, I've created a new profile and still the same thing. This is with a fresh install of Mozilla 2001030621 under Linux. I'll attach a screenshot and a copy of prefs.js for this profile just in case I'm doing something wrong.

I feel like a fool, I should have just had a look at the patch and I would have realised where I was going wrong. I should have set network.dir.generate_html as opposed to network.ftp.generate_html Setting network.dir.generate_html is working fine although we do need a way of going up to parent directories but that's another bug :) Anyway, definitely works Linux x86 build 2001030621

Duh! I should have noticed that too.

Dougt said: "One thing to note, is that this is a rough cut of a Indexed to HTML converter. We are only handling the 201 state. Any other states that are needed will come in as bugs. " Which states would you like me to file bugs against you for? :-) Gerv

gerv: The ones needed for me to hook gopher up to this? :) (200 is the only other used one, really) /me ducks Basically, nsHTTPIndexParser needs to be pulled out of nsDirectoryViewer.cpp (and placed somewhere else), and given a set of callback functions. Its not as simple at cut-and-pasting the code, because the parser isn't separated from the RDF datasource. I think. If you file a bug, please cc me on it.

Bradley: I'm way out of my depth here - I'm just a QA person ;-) Feel free to file said bugs if you know what to say in them... Gerv

Filed bug 72724 on getting gopher to do this.

verified