Web Dock is a Java applet that provides FTP access to a server, using a web-based interface. It will have Drag and Drop (to and from) and possibly Secure FTP.

I found it to be a pain to upload files I created on school computers, to my home server, because it required that I find and install an FTP client every time. Windows "Explorer" FTP is not reliable and shows my FTP password in the status bar. Windows console FTP requires I tediously traverse long directory names without tab-filename-completion, which I've become accustomed to in *NIX. I also needed a way to upload files conveniently from any operating system. Java was the solution.

I abandoned the project after I found it difficult to transfer files using Java because of the security restrictions it has built in. I, months later, saw web-based FTP clients written in Java and I revived the project since I found a proven method of file transfer. No, it never occurred to me to use FTP before, I live in shame.

Back to Main Page Current Page
 

View Demo of v0.5                                                                                                           
                                        
       Download v0.5 Preview                                                                        Current Screenshot              

  
May 13 - Java FTP Library
Though I briefly considered the idea, I decided against creating my own methods to interact with the FTP server. Mainly, because it would take forever and after completing the FTP back end I would no longer have any desire to complete the front end. I looked around for an Open Source Java library that handled FTP communication. I chose one by Tuomas Angervuori (http://www.hut.fi/~tangervu/) which provides unsecured FTP transfers.

 
May 19 - Design
Web Dock will be run as an applet and provide connection to the server the applet is served from. Java programs are run on the client machine, so a more useful application would be to allow Web Dock to connect to any server, and I may allow this later, but for now I will allow only connections to the serving system.

My original idea was to provide a list of files in a single directory (the Dock) and also have a side window that displayed a file description. This description was entered and edited using the Web Dock and was for general information about the file. Since it's purpose is to be a way for me to upload files from school to my home server I would use the files descriptions to remind myself what project the file was for, when it was due, or what things were left for me to do in order to complete it. As you see in the screenshot, I've left that part off because I'm focusing on getting the basic interface and FTP communication done. I may add the file descriptions on later.

The bottom window will show the command log of the FTP connection, so that if something goes wrong the user is not left blind. I want the progress bar at the bottom to show the progress of a transferring file. This may require that I change libraries, but I haven't delved too deep into Angervuori's yet.

 
June 17 - Directory Navigation
I've been working on and off on this but I'm back to making some progress. The directory navigation is finished which recognizes symbolic links that point to directories, as directories. I had to write two options for listings because the Microsoft FTP and Unix FTP file details and directory listing formats are different. I also converted the file sizes in the Simple listing (not file details, just the filename and the size) into human readable units. But the Detailed listing is still in its original bytes unit. I may make it human readable, but not now, there are more functional things to be completed.

During directory listings the UI freezes, so I set the listing function to run in it's own thread, but that didn't keep the message pump running to refresh the UI. It's a cosmetic issue and I will not deal with it now.

Next is the actual transferring of the files. This should not be as tedious as directory navigation was.

 

July 21 - File Transfers / Threads
I've modified the directory listing described above to run in its own thread properly so the UI doesn't stall. I will do the same for the file transfers, except that I won't have to write that thread because the ftp library by Angervuori has threaded routines already written. I will show the download progress in the bar under the Upload/Download buttons. That will require that I write another thread to handle the percent progress in order to allow for the UI to refresh for directory navigation etc.

I don't have to create a thread to handle the file transfers, but I do have to create another instance/connection of the ftp object, or else the ftp routines will stall until the file transfer is complete. Not a big deal, just create the new ftp object like the first one, connect using the same settings as the first one and change directory to the current directory of the first one. Then, start the threaded file transfer with the new ftp object. Now the UI stays alive, can take user input like directory changes, and the old ftp object is fully functional and can respond to the UI while the new ftp object is transferring a file.

I have the Communication Log at the bottom displayed, yet later I will probably remove it and create a button that will display it when desired, and use the real-estate to show download/upload queues.

Back to the threading of file transfers, this is how I programmed the progress bar:

progressMeter(); gets called right after the file transfer thread is started. The progressMeter() creates a thread...
that thread creates a timer... that timer updates the progress bar and text-labels every second (1000ms). The timer is used to keep the progress bar updates from saturating the CPU.

 
August 2 - FTP Variations
I took for granted that all FTP servers would operate the same, and they do to an extent. The major difference I've found is in the directory listing of Windows based and Unix based servers. Once I realized the difference I went back and hacked the necessary modifications. It's dirty, but works. I then made another assumption: that all Unix based servers have identical listings. I was wrong again, BSD servers do not always hide files with dotted first characters and have a line at the beginning, telling how many files are in the directory.

I see this as being a major issue since I have come to believe that there are variations in all types of FTP servers, and that the varaitions are not operating system based, but rather based on the individual servers themselves. This was not accounted for in the design and can involve many variations; therefore, I can no longer hack modifications into the single listing function, but rather might attempt to recognize the server type and write different directory listing functions for each type. Sounds good, but I can't really test all the available FTP servers out there and include thier modifications into the code. So I think I will have to beef up the listing routine and have it intelligently format the list by receiving the listing from the server and then, line-by-line, identify the parts of a directory listing that are the same in every FTP server: whether it's a regular file, directory, link or other directory information. Once the lines are parsed, then create a directory listing of the identified files in the format that is compatible with the WebDock's UI.

As it stands now, I crudely attempt to identify the server type from the SYS string, make assumtions about the way the server will list the directory, and then list the lines as they are, with a few lines (like ".", ".." and "# files") removed or added based on the server type. This a very simple way of doing it, but not, in any way, as robust as necessary. Using assumptions is not a very good way of solving problems, as I've learned before, so I think analyzing the lines and recreating the directory list every time is the best way to go. How I will, or even if I can, use Windows type links (.lnk) has yet to be seen.

 
August 4 - Preview Release 0.5
I've decided that since classes start again soon I will release a preview of what I've got so far.. since development will stop during the semester. The applet is disabled by your local computer's Java Virtual Machine security restrictions. Change your local policy to allow connections, or connect to your local domain to test the demo.